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Abstract 


This  research  paper  explores  the  use  of  the  modular  open  systems  approach 
(MOSA)  as  a  method  for  implementing  an  evolutionary  acquisition  strategy  and 
investigates  the  implications  of  using  the  MOSA  on  the  contracting  process.  First,  a 
background  on  evolutionary  acquisition  is  presented  from  a  perspective  of  current 
DoD  acquisition  regulations.  Next,  basic  concepts  of  open  systems  are  discussed, 
along  with  applications  of  the  open  systems  approach  to  defense  systems 
development  and  acquisition.  The  implications  of  using  a  modular  open  systems 
approach  on  the  contracting  process  is  then  presented,  with  a  focused  discussion  on 
the  various  contracting  activities  and  documents  related  to  each  phase  of  the 
contracting  process.  The  report  uses  the  generally  accepted  phases  of  the 
contracting  process — procurement  planning,  solicitation  planning,  solicitation,  source 
selection,  contract  administration,  and  contract  closeout  to  discuss  the  contracting 
activities  and  documents  that  should  be  affected  by  using  a  modular  open  systems 
approach.  Additionally,  a  brief  highlight  of  intellectual  property  issues  is  provided, 
along  with  a  review  of  the  applicable  major  regulatory  provisions.  The  research 
concludes  with  the  identification  of  the  characteristics  of  a  successful  MOSA 
program  procurement  and  resulting  contract  and  provides  areas  for  further  study. 

Key  Words:  evolutionary  acquisition,  contract  management,  open  systems, 
procurement,  systems  engineering. 
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Executive  Summary 


This  research  explores  the  use  of  the  modular  open  systems  approach 
(MOSA)  as  a  method  for  implementing  an  evolutionary  acquisition  strategy  as  well 
as  the  implications  of  using  such  an  approach  on  the  contracting  process. 

A  background  on  evolutionary  acquisition  is  provided  highlighting  the  benefit 
of  rapid  development  and  production  of  weapon  systems  incrementally,  with  each 
increment  providing  an  increasing  level  of  capability.  The  modular  open  systems 
approach  (MOSA)  is  identified  as  an  enabler  for  the  evolutionary  acquisition 
strategy,  and  a  brief  discussion  on  open  systems  is  provided. 

The  contractual  implications  of  using  a  modular  open  systems  approach  is 
then  discussed,  focusing  on  each  of  the  six  phases  of  the  procurement  process. 
Examples  of  MOSA-specific  contracting  activities  and  documents  are  taken  from 
recent  US  Navy  weapons  systems  acquisition  programs  such  as  the  Navy’s 
Common  Enterprise  Display  System  (CEDS)  program,  Anti-Submarine  Warfare 
(ASW)/Undersea  Warfare  (USW)  Test  Information  Management  System  program. 
Multi-mission  Maritime  Aircraft  (MMA)  program.  Littoral  Combat  Ship  (LCS)  Mission 
Package  Integrator  program.  Littoral  Combat  ship  (LCS)  Flight  0  Preliminary  Design 
program,  and  the  Navy’s  Mobile  User  Objective  System  (MUOS)  program. 
Additionally,  a  brief  highlight  of  intellectual  property  issues  is  provided,  along  with  a 
review  of  the  applicable  major  regulatory  provisions. 

The  research  identifies  the  following  characteristics  of  a  successful  MOSA 
program  procurement  and  resulting  contract:  Early  involvement  and  participation  of 
industry  in  the  development  of  requirements  and  acquisition  strategy;  shared  roles 
between  the  government  and  contractors  in  the  development  of  the  system 
specification  and  statement  of  work;  the  use  of  a  best-value  contract  strategy 
consisting  of  the  evaluation  of  offeror’s  technical,  schedule,  and  past  performance, 
as  well  as  the  offeror’s  cost  and  management  approach;  the  use  of  a  contract 
structure  consisting  of  contractor  incentives  for  meeting  higher  levels  of  “openness”; 


XI 


the  documentation  of  contractor’s  past  performance  in  meeting  “openness” 
requirements,  as  well  as  the  documentation  of  lessons  learned  and  best  practices  on 
open  systems. 

Finally,  the  report  recommends  that  further  research  be  conducted  on  the 
following  areas:  Other  DoD  acquisition  programs  to  evaluate  the  extent  to  which  the 
identified  MOSA  contracting  best  practices  and  characteristics  have  been 
implemented  in  those  departments;  the  effectiveness  of  award  fee  and  award  term 
provisions  in  incentivizing  contractors  to  achieve  higher  levels  of  openness  in 
designing  and  developing  weapon  systems,  given  the  recent  GAO  findings 
concerning  the  use  of  award  fees  in  DoD  contracts;  an  analysis  of  current  major 
weapon  system  acquisition  programs  status  of  MOSA  implementation  that  is  a 
required  milestone  review  briefing  point  to  the  program’s  Milestone  Decision 
Authority;  the  results  of  any  OSJTF  Program  Assessment  Rating  Tool  (PART) 
internal  MOSA  assessments  on  current  defense  acquisition  programs;  and,  finally, 
the  type  and  extent  of  training  that  is  currently  provided  to  contracting  officers  in  the 
area  of  MOSA-based  acquisition  strategies. 
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Introduction 


Department  of  Defense  (DoD)  weapon  system  acquisition  programs  continue 
to  suffer  from  cost  and  schedule  overruns,  as  well  as  operational  performance 
deficiencies  (GAO,  2005,  November  15).  In  its  many  attempts  to  reinvent,  reform, 
and  transform  what  some  consider  a  “broken  acquisition  process”  (Johnson  & 
Johnson,  2002),  the  DoD  has  been  continuously  implementing  various  initiatives 
within  and  policy  changes  to  its  acquisition  and  procurement  processes  (Rogers  & 
Birmingham,  2004).  Faced  with  the  challenges  of  the  Global  War  on  Terrorism  and 
the  fiscal  battles  of  budget  cuts  and  resource  constraints,  the  DoD  is  ambitiously 
trying  to  improve  its  weapon  system  acquisition  policies  and  practices  in  order  to 
more  effectively  and  efficiently  develop  weapon  systems  with  technological 
superiority  and  enhanced  lethality. 

The  most  recent  and  probably  the  most  unprecedented  change  to  the  DoD 
acquisition  policy  has  been  the  issuance  of  the  latest  revision  to  the  DoD  5000 
series  of  acquisition  policy  regulations  (Under  Secretary  of  Defense  (AT&L),  2003, 
May  12a;  2003,  May  12b).  These  revised  regulations,  which  took  the  place  of  those 
previously  cancelled  for  not  being  conducive  to  an  acquisition  environment  that 
fosters  flexibility,  efficiency,  creativity,  and  innovation  (Rogers  &  Birmingham,  2004), 
provide  acquisition  managers  a  significant  amount  of  flexibility  in  structuring  and 
managing  weapon  system  development  programs.  One  method  of  providing 
flexibility  into  weapon  system  development  has  been  the  DoD  preference  for  the  use 
of  evolutionary  acquisition  strategies  in  the  development  process.  Consistent  with 
the  evolutionary  approach  is  the  use  of  modular  open  systems  in  the  design  and 
development  of  defense  weapons  and  related  systems.  Using  a  modular  open 
systems  approach  (MOSA)  has  significant  implications  for  the  various  aspects  of  the 
acquisition  program,  such  as  requirements  management,  systems  engineering, 
contract  management,  and  logistics  management,  just  to  name  a  few. 

The  purpose  of  this  research  paper  is  to  explore  the  use  of  the  modular  open 
systems  approach  (MOSA)  as  a  method  for  implementing  an  evolutionary 
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acquisition  strategy,  and  then  to  investigate  the  implications  of  using  the  MOSA 
approach  on  the  contracting  process.  First,  some  background  on  evolutionary 
acquisition  will  be  presented  from  a  perspective  of  the  current  DoD  acquisition 
regulations.  Next,  basic  concepts  of  open  systems  will  be  discussed,  along  with 
applications  of  the  open  systems  approach  to  defense  systems  development  and 
acquisition.  The  implications  of  using  a  modular  open  systems  approach  on  the 
contracting  process  will  then  be  presented,  with  a  focused  discussion  on  the  various 
activities  and  contractual  documents  related  to  each  phase  of  the  contracting 
process.  The  research  will  then  conclude  with  the  identification  of  characteristics  of 
a  successful  MOSA  program  procurement  and  resulting  contract. 
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Evolutionary  Acquisition 


On  30  October,  2002,  Deputy  Undersecretary  of  Defense  for  Acquisition, 
Technology  and  Logistics  [DUSD  (AT&L)]  Paul  Wolfowitz  issued  a  memo  canceling 
the  DoD  5000  series  of  acquisition  policy  documents  stating  they  were,  “Overly 
prescriptive  and  do  not  constitute  an  acquisition  policy  environment  that  fosters 
efficiency,  creativity,  and  innovation”  (Wolfowitz,  2002).  On  May  12,  2003,  the 
DUSD  (AT&L)  officially  implemented  the  revised  DoD  5000  series  documents  with  a 
policy  focus  on  flexibility,  responsiveness,  innovation,  discipline,  and  streamlined 
and  effective  management  (Under  Secretary  of  Defense  (AT&L),  2003,  May  12a; 
2003,  May  12b).  Included  in  the  updated  DoD  acquisition  policy  directive  is  a 
preference  for  evolutionary  acquisition.  The  Defense  Acquisition  University’s  (DAU) 
Glossary  of  Defense  Acquisition  Acronym  and  Terms  {Glossary,  2003)  defines 
evolutionary  acquisition  as  the  following: 

Evolutionary  Acquisition  (EA)  The  preferred  DoD  strategy  for  rapid 
acquisition  of  mature  technology  for  the  user  according  to  DoD  I 
5000.2.  An  evolutionary  approach  delivers  capability  in  increments, 
recognizing  up  front  the  need  for  future  capability  improvements.  There 
are  two  approaches  to  achieving  an  EA;  Spiral  Development  and 
Incremental  Development  as  noted  below: 

Spiral  Development:  In  this  process,  a  desired  capability  is  identified, 
but  the  end-state  requirements  are  not  known  at  program  initiation. 
Requirements  are  refined  through  demonstration,  risk  management, 
and  continuous  user  feedback.  Each  increment  provides  the  best 
possible  capability,  but  the  requirements  for  future  increments  depend 
on  user  feedback  and  technology  maturation.  According  to  DoDD 
5000.1,  spiral  development  is  the  preferred  process  for  executing  an 
EA  strategy. 
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Incremental  Development:  In  this  process,  a  desired  capability  is 
identified,  an  end-state  requirement  is  known,  and  that  requirement  is 
met  over  time  by  developing  several  increments,  each  dependent  on 
available  mature  technology. 

Evolutionary  acquisition,  then,  is  focused  on  rapidly  developing  and  producing 
weapon  systems,  hardware  or  software,  incrementally,  with  each  increment 
providing  an  increasing  level  of  operational  capability.  Evolutionary  acquisition 
allows  the  development  and  acquisition  of  weapon  systems  to  evolve  over  time,  as 
technologies  are  matured  and  proven  in  the  field.  With  evolutionary  acquisition, 
weapon  systems  can  be  fielded  in  a  more  timely  manner,  albeit,  with  an  initial 
increment  of  capability  (for  example,  an  80%  solution),  as  opposed  to  a  fully  capable 
system  (100%  solution)  from  the  outset.  The  traditional  acquisition  strategy  is  based 
on  developing  and  fielding  a  weapon  system  that  attempts  to  accomplish  the  mission 
(100%  solution)  at  the  initial  deployment.  As  described  in  the  DoD  Directive  5000.2 
and  Figure  1,  the  evolutionary  acquisition  strategy  can  be  approached  using  either  a 
spiral  development  or  incremental  development  method. 
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Figure  1.  Requirements  and  Acquisition  Process  Depiction 


The  difference  between  the  two  approaches  is  that  in  the  Spiral  Development 
method,  the  end-state  requirements  are  not  known  at  program  initiation.  Each 
increment  provides  the  best  possible  capability,  but  the  requirements  for  future 
increments  depend  on  user  feedback  and  technology  maturation.  In  the  Incremental 
Development  method,  the  end-state  requirement  is  known,  and  that  requirement  is 
met  over  time  by  developing  several  increments,  each  dependent  on  available 
mature  technology  (Under  Secretary  of  Defense  (AT&L),  2003,  May  12a;  2003,  May 
12b).  The  Air  Force  Global  Hawk  program  is  considered  to  be  the  leading  pioneer  in 
implementing  evolutionary  acquisition  using  a  spiral  development  approach  (Novak 
et  al.,  2004). 

Thus,  evolutionary  acquisition  is  aimed  at  reducing  acquisition  cycle-time  and 
reducing  risk  in  the  development  of  operationally  effective  systems.  Evolutionary 
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acquisition  is  the  preferred  approach,  and  spiral  development  is  the  preferred 
process  for  executing  evolutionary  acquisition  (Under  Secretary  of  Defense  (AT&L), 
2003,  May  12a;  2003,  May12b). 

A  key  enabler  for  implementing  evolutionary  acquisition  strategies  is  the  use 
of  a  modular  open  systems  approach  (MOSA)  in  the  design  and  development  of 
weapons  and  related  systems.  MOSA  will  allow  for  a  more  efficient  and  effective 
method  for  increasing  the  technological  capability  of  developed  systems,  thus 
supporting  an  incremental  or  spiral  development  evolutionary  acquisition  strategy. 
The  next  section  of  this  paper  will  introduce  the  modular  open  systems  approach 
and  discuss  the  basic  concepts  of  open  systems  as  well  as  the  applications  of  the 
modular  open  systems  approach  to  defense  systems  development  and  acquisition. 


6 


The  Open  Systems  Approach 


DoD  5000.1  states  that  “a  modular  open  systems  approach  shall  be 
employed  where  feasible”  (Under  Secretary  of  Defense  (AT&L),  2003,  May  12a). 
Furthermore,  in  April  2004,  the  USD  (AT&L)  issued  a  memorandum  stating,  “all 
programs  subject  to  milestone  review  shall  brief  their  program’s  MOSA 
implementation  status  to  the  Milestone  Decision  Authority  (MDA)  to  determine 
compliance”  (Under  Secretary  of  Defense  (AT&L),  2004,  April  5).  Later  that  year, 
the  Office  of  the  USD(AT&L),  Director  of  Defense  Systems,  issued  instructions  for 
MOSA  implementation  and  identified  the  Open  System  Joint  Task  Force  (OSJTF)  as 
the  DoD  lead  for  MOSA.  This  memo  also  identified  MOSA  as  “an  integral  part  of  the 
toolset  that  will  help  DoD  achieve  its  goal  of  providing  the  joint  combat  capabilities 
required  in  the  21  century,  including  supporting  and  evolving  these  capabilities  over 
their  total  life-cycle”  (Under  Secretary  of  Defense  (AT&L),  2004,  July  7). 

The  OSJTF  identified  the  modular  open  systems  approach  as  being  an 
enabler  to  achieving  the  following  objectives  {OSJTF  guide,  2004): 

•  Adapt  to  evolving  requirements  and  threats 

•  Promote  transition  from  science  and  technology  into  acquisition  and 
deployment 

•  Facilitate  systems  integration 

•  Leverage  commercial  investment 

•  Reduce  the  development  cycle-time  and  total  lifecycle  cost 

•  Ensure  that  the  system  will  be  fully  interoperable  with  all  the  systems  with 
which  it  must  interface,  without  major  modification  of  existing  components 

•  Enhance  commonality  and  reuse  of  components  among  systems 

•  Enhance  access  to  cutting  edge  technologies  and  products  from  multiple 
suppliers 

•  Mitigate  the  risks  associated  with  technology  obsolescence 

•  Mitigate  the  risk  of  a  single  source  of  supply  over  the  life  of  a  system 
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•  Enhance  lifecycle  supportability 

•  Increase  competition 

OSJTF  has  developed  the  Program  Assessment  Rating  Tool  (PART)  for 
conducting  internal  MOSA  implementation  assessments  (Undersecretary  of  Defense 
(AT&L),  2004,  July  7).  These  recent  policy  directives  are  reflective  of  the  increased 
emphasis  the  DoD  is  placing  on  using  an  open-systems  approach. 

It  should  be  noted  that  various  terms  have  been  used  to  describe  various 
aspects  of  “open  systems.”  The  following  is  an  initial  explanation  of  key  terms  and 
definitions  that  will  be  referred  to  in  this  study: 

Modular  Open  Systems  Approach  (MOSA):  An  integrated  business 
and  technical  strategy  that  employs  a  modular  design  and,  where 
appropriate,  defines  key  interfaces  using  widely  supported,  consensus- 
based  standards  that  are  published  and  maintained  by  a  recognized 
industry  standards  organization.  {OSJTF  guide,  2004) 

Open  Architecture:  An  architecture  that  employs  open  standards  for 
key  interfaces  within  a  system.  {OSJTF  guide,  2004) 

Open  Standards:  Standards  that  are  widely  used,  consensus  based, 
published  and  maintained  by  recognized  industry  standards 
organizations.  {OSJTF  guide,  2004) 

Open  System:  A  system  that  employs  modular  design,  uses  widely 
supported  and  consensus-based  standards  for  its  key  interfaces,  and  has 
been  subjected  to  successful  validation  and  verification  tests  to  ensure  the 
openness  of  its  key  interfaces.  {OSJTF  guide,  2004) 

Open  Systems  Acquisition  of  Weapons  Systems:  An  integrated  technical 
and  business  strategy  that  defines  key  interfaces  for  a  system  (or  a  piece  of 
equipment  under  development)  in  accordance  with  those  adopted  by  formal 
consensus  bodies  (recognized  industry  standards  bodies)  as  specifications 
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and  standards,  or  commonly  accepted  (de  facto)  standards  (both  company 
proprietary  and  non-proprietary)  if  they  facilitate  utilization  of  multiple 
suppliers.  {Glossary,  2005) 

Open  Systems  Environment  (OSE):  A  comprehensive  set  of  interfaces, 
services,  and  supporting  formats,  plus  aspects  of  interoperability  of 
application,  as  specified  by  Information  Technology  (IT)  standards  and 
profiles.  An  OSE  enables  information  systems  to  be  developed,  operated,  and 
maintained  independent  of  application-specific  technical  solutions  or  vendor 
products.  {Glossary,  2005) 

As  can  be  seen  from  the  above  definitions,  there  are  unique  differences  within 
the  various  “open-related”  terms.  The  unique  differences  noted,  for  the  basis  of  this 
research,  focus  on  the  distinction  between  strategy  and  system.  The  Modular  Open 
Systems  Approach  (MOSA)  term  focuses  on  the  strategy,  specifically,  an  integrated 
business  and  technical  strategy  that  employs  the  various  components  of  an  open 
system.  The  Open  System  term  focuses  on  the  technical  aspects  of  the  system  and 
its  components,  such  as  modular  design,  open  standards,  open  architecture.  This 
seems  to  be  effectively  delineated  in  the  Definitions  section  of  the  OSJTF  Program 
Manager’s  Guide  to  a  Modular  Open  Systems  Approach  (MOSA)  to  Acquisition. 

The  DAU  Glossary’s  unique  terms  are  not  as  clear  in  this  delineation.  It  is  this 
author’s  interpretation  of  the  DAU  Glossary  that  Open  Systems  Acquisition  of 
Weapons  Systems  refers  to  the  integrated  strategy  focus,  while  the  Open  Systems 
Environment  (OSE)  refers  to  the  technical  aspects  of  open  systems,  specifically 
interfaces  services  and  formats.  For  the  purpose  of  this  research,  the  term  Modular 
Open  Systems  Approach  (MOSA)  will  refer  to  the  integrated  strategy,  which  involves 
the  use  of  open  systems,  and  the  term  Open  Systems  will  refer  to  the  technical 
aspects  of  developing  and  using  an  open  system.  The  following  section  will  discuss 
open  systems,  the  modular  open  systems  approach  (MOSA),  and  its  applications  in 
defense  systems  development  and  acquisition. 
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Open  Systems  and  Modular  Open  Systems  Approach  (MOSA) 

The  modular  open  systems  approach  is  considered  an  enabler  to  successfully 
implementing  an  Evolutionary  Acquisition  strategy.  While  Evolutionary  Acquisition 
focuses  on  rapidly  developing  and  producing  weapon  systems  incrementally,  with 
each  increment  providing  an  increasing  level  of  operational  capability,  the  modular 
open  systems  approach  ensures  access  to  the  latest  technologies  and  products  and 
facilitates  affordable  and  supportable  system  development  and  modernization  of 
fielded  assets  {Defense  acquisition  guidebook,  2004). 

The  Defense  Acquisition  Guidebook  {DAG)  states  that  “an  open  system  is  a 
system  that  employs  modular  design  tenets,  uses  widely  supported  and  consensus 
based  standards  for  its  key  interfaces,  and  is  subject  to  validation  and  verification 
tests  to  ensure  the  openness  of  its  key  interfaces”  {Defense  acquisition  guidebook, 
2004).  The  OSJTF  defines  modular  open  systems  approach  (MOSA)  as: 

An  integrated  business  and  technical  strategy  that  employs  a  modular  design 
and,  where  appropriate,  defines  key  interfaces  using  widely  supported, 
consensus-based  standards  that  are  published  and  maintained  by  a 
recognized  industry  standards  organization  {OSJTF  guide,  2004). 

This  definition  focuses  on  the  key  aspect  of  “an  integrated  business  and 
technical  strategy,”  thus,  using  an  open  systems  approach  is  as  much  about 
business  strategy  as  it  is  about  technical  strategy  and  requirements. 

A  technical  definition  of  an  open  system  is  provided  by  Meyers  and 
Oberndorf: 

a  collection  of  interacting  software  and  hardware  component 
implementations,  and  users  designed  to  satisfy  stated  needs,  having  the 
interface  specification  of  components  fully  defined,  available  to  the  public,  and 
maintained  according  to  group  consensus,  in  which  the  component 
implementations  conform  to  the  interface  specification.  (2001,  p.  12) 
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Key  to  this  definition  of  open  systems  is  the  “fully  defined  interface  specification,” 
“available  to  the  public,”  and  “maintained  according  to  a  group  consensus,”  since 
these  aspects  of  open  systems  provide  the  desired  results  of  portable 
implementation  and  interoperability.  Other  advantages  of  using  an  open  system 
approach  include  lower  costs,  less  reliance  on  proprietary  solutions,  shorter 
development  schedule,  better  tested  products,  and  more  stable  technology  insertion. 
Of  course,  some  of  the  disadvantages  of  using  an  open  system  approach  include 
higher  cost,  higher  risk,  inability  to  meet  special  requirements,  and  conformance  and 
support  problems  (Meyers  &  Oberndorf,  2001). 

Given  these  advantages  and  disadvantages  of  using  an  open  systems 
approach,  and  notwithstanding  the  USD(AT&L)  policy,  the  Defense  Acquisition 
Guide  (DAG)  stresses  that  program  managers  should  employ  an  open  systems 
approach  only  after  conducting  a  business  case  analysis  considering  trade  studies, 
cost  models,  and  market  research.  This  business  case  analysis  should  focus  on 
analyzing  technology  and  open  standard  trends,  as  well  as  the  level  of  market 
support  for  these  needed  technologies  and  standards  {Defense  acquisition 
guidebook,  2004).  More  specifically,  the  DAG  states: 

Program  managers  should  employ  an  open  systems  design  strategy  only 
after  careful  analysis  of  required  capabilities  and  strategies  for  technology 
development,  acquisition,  test  and  evaluation,  and  product  support.  They 
should  also  analyze  the  impacts  of  information  assurance,  systems  safety 
and  security,  commercial,  off-the-shelf  availability,  and  other  design 
considerations  before  finalizing  their  open  systems  design  strategy.  (2004) 

Meyers  and  Oberndorf  identify  seven  elements  of  an  open  systems  approach. 
They  describe  these  seven  elements  as  follows  (2001): 

1.  Requirements:  Establishing  a  system  baseline  in  terms  of  standards 
and  commercial-of-the-shelf  (COTS)  products,  specifying  system 
requirements  and  prioritizing  requirements. 
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2.  Reference  Models:  Creating  a  high-level  system  model  that  defines 
terminology  and  concepts. 

3.  Components  and  Interfaces:  This  involves  documenting  the 
architecture  to  reflect  the  evaluation  of  architectural  approaches,  as  well 
as  the  identification  of  components,  the  survey  of  technology,  and 
prototyping. 

4.  Standards:  Documenting  standards  coordination  reflecting  the 
evaluation  and  selection  of  standards,  establishing  liaisons  with  standards 
bodies  and  users  groups,  as  well  as  resolving  inconsistencies  between 
standards. 

5.  Implementations:  Implementing  selected  standards  resulting  from  the 
evaluation,  selection,  procurement,  and  testing  of  these  standards. 

6.  Integration  and  Testing:  This  involves  the  integration  of  component 
implementations  and  the  testing  of  the  integrated  system. 

7.  Deployment  and  Support:  The  distribution  and  maintenance  of  the 
system,  including  all  related  lifecycle  maintenance. 

Meyers  and  Oberndorf  describe  these  seven  elements  as  having  an  iterative 
and  interactive  relationship.  Specifically,  the  components  and  interfaces,  standards, 
and  implementation  elements  have  an  iterative  relationship  with  each  other,  as  well 
as  with  the  other  four  elements.  Figure  2  reflects  the  iterative  and  interactive  nature 
of  all  seven  elements  of  the  open  system  approach  (2001). 
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Figure  2.  Iteration  and  Interaction  of  Open  System  Approach  Elements 


Source:  Adapted  from  Managing  Softvjare  Acquisition:  Open  Systems  and 
COTS  Products.  Meyers  and  Oberndorf,  Addison-Wesley,  2001. 
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MOSA  and  Evolutionary  Acquisition 


As  previously  stated,  the  open  systems  approach  is  considered  an  enabler  to 
successfully  implementing  an  evolutionary  acquisition  strategy.  The  use  of  an  open 
systems  approach  is  just  one  consideration  which  the  program  manager  must  make 
in  developing  an  acquisition  strategy.  In  developing  an  acquisition  strategy,  the 
program  manager  must  consider  a  variety  of  topics  and  activities  to  include  in  the 
acquisition.  The  Defense  Acquisition  Guidebook  {DAG)  lists  eighteen  different  areas 
to  consider  in  developing  an  acquisition  strategy — a  modular  open  systems 
approach  is  one  of  those  considerations.  The  DAG  also  identifies  the  use  of  an 
open  systems  approach  as  a  best  practice  that  avoids  imposing  Government-unique 
restrictions  that  significantly  increase  industry  compliance  cost  or  unnecessarily 
deter  qualified  contractors,  including  non-traditional  defense  firms,  from  submitting  a 
proposal.  The  open  systems  approach  is  also  identified  as  an  example  of  a  robust 
systems  engineering  process  that  ensures  that  systems  are  designed  to  easily  and 
affordably  accommodate  additive  capabilities  in  subsequent  increments  {Defense 
acquisition  guidebook,  2004). 

Specifically,  the  DAG  states  that  the  program  manager  should  plan  for  MOSA 
implementation  and  include  a  summary  of  such  planning  as  part  of  the  overall 
acquisition  strategy  and,  to  the  extent  feasible,  the  technology  development  strategy. 
The  summary  of  the  MOSA  planning  should  describe: 

1 .  How  MOSA  fits  into  a  program's  overall  acquisition  process  and  strategies 
for  acquisition,  technology  development,  and  T&E; 

2.  What  steps  a  program  will  take  to  analyze,  develop,  and  implement  a 
system  or  a  system -of-systems  architecture  based  on  MOSA  principles, 
and 

3.  How  such  a  program  intends  to  monitor  and  assess  its  MOSA 
implementation  progress  and  ensure  system  openness.  (2004) 

A  business  case  analysis  for  using  an  open  systems  design  should  be 
conducted  by  the  program  manager.  This  analysis  should  include  market  research. 
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dynamic  cost  models,  and  trade  studies.  Furthermore,  if  program  managers  decide 
to  implement  an  open  systems  approach,  their  MOSA  plan  should  consider  the  five 
MOSA  principles  listed  below,  and  also  described  in  the  Open  Systems  Joint  Task 
Force  Guide  to  MOSA  {Defense  acquisition  guidebook,  2004;  OSJTF  guide,  2004). 

Establish  an  Enabling  Environment 

This  involves  establishing  supportive  requirements,  business  practices,  and 
strategies  for  technology  development,  acquisition,  test  and  evaluation  and  product 
support  needed  for  the  effective  development  of  open  systems.  Also  included  are 
the  following:  assigning  responsibility  for  MOSA  implementation,  ensuring 
appropriate  experience  and  training  on  MOSA,  continuing  market  research  and 
proactive  identification,  and  overcoming  of  barriers  or  obstacles  that  can  potentially 
slow  down  or  even,  in  some  cases,  undermine  effective  MOSA  implementation. 

Employ  Modular  Design 

Effective  modular  design  refers  to  the  four  major  modular  design  tenets  of 
Cohesiveness  (the  module  contains  well-focused  and  well-defined  functionality). 
Encapsulation  (the  module  hides  the  internal  workings  of  its  behavior  and  its  data), 
Self-Containment  (the  module  does  not  constrain  other  modules),  and  Highly  Binded 
(the  modules  use  broad  modular  definitions  to  enable  commonality  and  reuse).  This 
principle  states  that  by  following  these  four  tenets,  each  module  will  be  designed  for 
change,  and  the  interface  to  each  module  will  be  defined  in  such  a  way  as  to  reveal 
as  little  as  possible  about  its  inner  workings  which  facilitate  the  standardization  of 
modular  interfaces. 

Designate  Key  Interfaces 

This  principle  stresses  that  designers  should  group  interfaces  into  two 
categories — key  and  non-key  interfaces.  Such  distinction  enables  designers  and 
configuration  managers  to  distinguish  among  interfaces  that  exist  between 
technologically  stable  and  volatile  modules,  between  highly  reliable  and  more 
frequently  failing  modules,  between  modules  that  are  essential  for  net-centricity  and 
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those  that  do  not  perform  net-centric  functions,  and  between  modules  that  pass  vital 
interoperability  information  and  those  with  least  interoperability  impact.  Employing 
this  principle  will  help  acquisition  managers  effectively  manage  hundreds  and,  in 
some  cases,  thousands  of  interfaces  that  exist  within  and  among  systems.  Figure  3 
illustrates  how  the  MOSA  approach  distinguishes  between  key  and  non-key 
interfaces,  with  the  key  interfaces  utilizing  open  standards  in  order  to  reap  the  most 
lifecycle  cost  benefits  {OSJTF  guide,  2004). 

Figure  3.  Types  of  System  Interfaces 


Source:  Program  Managers  Guide:  A  Modular  Open 
Systems  Approach  (MOSA)  to  Acquisition.  Open  Systems 
Joint  Task  Force,  September  2004 


17 


Use  Open  Standards 

This  principle  stresses  that  standards  should  be  selected  based  on  maturity, 
market  acceptance,  and  allowance  for  future  technology  insertion.  Since  interface 
standards  must  be  well  defined,  mature,  widely  used  and  readily  available,  the 
principle  refers  to  the  order  of  priority  given  to  the  use  of  open  interfaces. 

Preference  is  given  to  the  use  of  open  interface  standards  first,  the  de  facto  interface 
standards  second,  and  finally,  government  and  proprietary  interface  standards. 
Basing  design  strategies  on  widely  supported  open  standards  increases  the  chance 
that  future  changes  will  be  able  to  be  integrated  in  a  cost  effective  manner. 

Certify  Conformance 

This  principle  focuses  on  the  verification  and  validation  of  a  system’s 
openness  through  the  use  of  such  mechanisms  as  interface  control  and 
management  as  well  as  proactive  conformance  testing  and  certification.  Using 
these  mechanisms,  the  program  manager  ensures  that  the  system  and  its 
component  modules  conform  to  the  external  and  internal  open  interface  standards 
allowing  plug-and-play  of  modules,  net-centric  information  exchange,  and  re¬ 
configuration  of  mission  capability  in  response  to  new  threats  and  evolving 
technologies.  A  preference  is  made  for  the  use  of  the  MOSA  Program  Assessment 
and  Review  Tool  (PART)  developed  by  the  Open  Systems  Joint  Task  Force  (OSTJ) 
to  assess  the  compliance  with  open  systems  policies  and  ensure  that  acquisition 
programs  are  properly  positioned  to  reap  the  open  systems  benefits  {Defense 
acquisition  guidebook,  2004). 

Program  offices  should  follow  these  five  MOSA  principles  to  guide  their  efforts 
in  ensuring  access  to  the  latest  technologies  and  products,  achieving 
interoperability,  and  facilitating  affordable  and  supportable  modernization  of  fielded 
assets.  Following  these  principles  will  also  be  needed  to  ensure  delivery  of 
technologically  superior,  sustainable,  and  affordable  increments  of  militarily  useful 
capability  within  an  evolutionary  acquisition  strategy  context.  As  program  offices  use 
these  five  MOSA  principles  to  guide  their  implementation  of  a  modular  open  system 
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approach  in  their  acquisition  programs,  the  implications  of  these  principles  should 
permeate  throughout  all  aspects  of  the  acquisition  process.  One  major  area  in 
which  the  MOSA  strategy  should  have  a  significant  influence  is  the  contracting 
process.  The  implications  of  using  a  MOSA  approach  to  acquisition  and  contracting 
will  be  discussed  in  the  next  section  of  this  paper. 
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Contractual  Implications 


The  defense  acquisition  process  consists  of  an  integrated  framework 
involving  many  different  functional  areas — including  engineering,  test  and 
evaluation,  manufacturing  and  production  and  logistics,  to  name  just  a  few.  The 
various  functional  areas  are  integrated,  typically  through  the  formation  of  multi¬ 
functional  teams,  or  integrated  product  teams  (IPTs),  to  facilitate  the  delivery  of  a 
specific  supply  or  service  to  the  ultimate  user  (Engelbeck,  2002).  One  of  the  most 
critical,  yet  frustrating  and  convoluted  functional  area  within  acquisition  is  the 
contracting  process.  The  contracting  process,  with  its  intricate  web  of  statutory 
policies,  rules,  and  procedures  is  already  a  challenging  area  of  any  traditional 
acquisition  program.  Given  the  dynamics  and  twists  of  an  evolutionary  acquisition 
program,  complete  with  increments  and  spirals,  the  use  of  an  open  systems 
approach  will  only  make  the  contracting  process  that  much  more  challenging.  This 
is  the  focus  of  the  remainder  of  this  paper — to  identify  what  are  the  implications  on 
the  contracting  process  of  using  a  MOSA  approach  in  an  evolutionary  acquisition 
program.  A  specific  focus  will  be  on  MOSA  implications  on  the  six  phases  of  the 
contracting  process — procurement  planning,  solicitation  planning,  solicitation,  source 
selection,  contract  administration,  and  contract  closeout.  This  section  will  first 
discuss  the  policy  and  guidance  provided  in  the  Federal  Acquisition  Regulation 
(FAR)  for  use  by  contracting  officers  in  an  acquisition  program  using  a  modular  open 
systems  approach.  Then  the  various  approaches  to  determining  the  roles  and 
responsibilities  of  the  government  and  contractor  in  a  MOSA-based  acquisition  will 
be  discussed.  The  research  will  then  identify  any  specific  contracting  activity  or 
documents  that  should  be  impacted  by  pursuing  a  modular  open  systems  approach 
to  a  weapon  system  acquisition.  Finally,  the  research  will  conclude  with  the 
identification  of  characteristics  of  a  successful  MOSA  program  acquisition  and 
resulting  contract. 
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Contracting  Policy  and  Guidance 

In  July  1996,  Executive  Order  (EO)  13011,  Federal  Information  Technology, 
was  issued  to  improve  information  system  acquisition  management.  Specifically, 
Section  2(e)ofE.O.  13011  requires: 

(e)  where  appropriate,  and  in  accordance  with  the  Federal  Acquisition 
Regulation  and  guidance  to  be  issued  by  the  Office  of  Management  and 
Budget  (0MB),  structure  major  information  systems  investments  into 
manageable  projects  as  narrow  in  scope  and  brief  in  duration  as  practicable, 
consistent  with  the  Information  Technology  Act,  to  reduce  risk,  promote 
flexibility  and  interoperability,  increase  accountability,  and  better  correlate 
mission  need  with  current  technology  and  market  conditions.  (Federal 
register,  1996) 

It  was  not  until  February  1998  that  the  Federal  Acquisition  Regulation  (FAR) 
added  specific  guidance  concerning  using  a  modular  contracting  approach.  With 
Federal  Acquisition  Circular  (FAC)  97-04,  the  FAR  incorporated  “modular 
contracting”  into  FAR  Part  39,  Acquisition  of  Information  Technology,  as  a  preferred 
method  for  acquiring  major  systems  of  information  technology.  Defining  “modular 
contracting”  as  “using  one  or  more  contracts  to  acquire  information  technology 
systems  in  successive  interoperable  increments,”  the  FAR  states  that  modular 
contracting  is  “intended  to  reduce  program  risk  and  to  incentivize  contractor 
performance  while  meeting  the  government  needs  for  timely  access  to  rapidly 
changing  technology”  (FAR,  39.103).  The  FAR  also  states  that  when  using  modular 
contracting,  the  acquisition  of  an  information  technology  system  may  be  divided  into 
several  smaller  acquisition  increments  that: 

1 .  Are  easier  to  manage  individually  than  would  be  possible  in  one 
comprehensive  acquisition; 

2.  Address  complex  information  technology  objectives  incrementally  in  order 
to  enhance  the  likelihood  of  achieving  workable  systems  or  solutions  for 
attainment  of  those  objectives; 
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3.  Provide  for  delivery,  implementation,  and  testing  of  workable  systems  or 
solutions  in  discrete  increments,  each  of  which  comprises  a  system  or 
solution  that  is  not  dependent  on  any  subsequent  increment  in  order  to 
perform  its  principal  functions; 

4.  Provide  an  opportunity  for  subsequent  increments  to  take  advantage  of 
any  evolution  in  technology  or  needs  that  occur  during  implementation  and 
use  of  the  earlier  increments;  and 

5.  Reduce  risk  of  potential  adverse  consequences  on  the  overall  project  by 
isolating  and  avoiding  custom-designed  components  of  the  system.  (FAR, 
39.103) 

In  providing  guidance  on  the  characteristics  of  an  increment  acquired  in  using 
a  modular  contracting  approach,  the  FAR  states  that: 

(1)  To  promote  compatibility,  the  information  technology  acquired  through 
modular  contracting  for  each  increment  should  comply  with  common  or 
commercially  acceptable  information  technology  standards  when 
available  and  appropriate,  and  shall  conform  to  the  agency’s  master 
information  technology  architecture. 

(2)  The  performance  requirements  of  each  increment  should  be  consistent 
with  the  performance  requirements  of  the  completed,  overall  system  within 
which  the  information  technology  will  function  and  should  address 
interface  requirements  with  succeeding  increments.  (FAR,  39.103) 

Finally,  the  FAR  guidance  concerning  contract  type  and  method  for  use  in 
modular  contracting  directs  contracting  officers  to  choose  an  appropriate  contracting 
technique  that  facilitates  the  acquisition  of  subsequent  increments.  The  FAR  states 
that  contracting  officers  shall  select  the  contract  type  and  method,  pursuant  to  FAR 
Parts  16  and  17,  appropriate  to  the  circumstance.  These  contract  types  include 
indefinite  delivery/indefinite  quantity  contracts,  single  contract  with  options, 
successive  contracts,  multiple  awards,  and  task  order  contracts  (FAR,  39.103). 

It  should  be  noted  that  the  FAR  Part  39  guidance  on  modular  contracting  is 
specifically  geared  to  the  acquisition  of  commercial  information  technology  systems 
and  not  necessarily  to  weapon  system  acquisitions  or  even  DoD  software  intensive 
systems.  Although  information  technology  systems  are  an  integral  part  of  the  DoD 
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infrastructure,  this  research  paper  will  focus  on  the  contractual  implications  of  using 
a  modular  open  systems  approach  in  the  acquisition  of  defense  weapon  systems 
and  specifically,  the  acquisition  of  software-intensive  weapon  systems.  In 
conducting  this  research,  a  specific  emphasis  will  also  be  placed  on  the  roles  and 
responsibilities  of  the  government  and  industry  during  the  acquisition  program  and 
the  specific  procurement  processes  consisting  of  procurement  planning,  solicitation 
planning,  solicitation,  source  selection,  contract  administration,  and  contract 
closeout. 

In  addition  to  the  Federal  Acquisition  Regulation  (FAR),  there  are  other 
sources  of  contracting  guidance  for  using  a  modular  open  systems  approach  in  an 
acquisition  program.  These  sources  include  (see  List  of  References): 

Open  Systems  Joint  Task  Force  (OSJTF)  Program  Manager’s  Guide  to  a 

Modular  Open  Systems  Approach  (MOSA)  to  Acquisition  (2004) 

Office  of  the  Undersecretary  of  Defense  (OUSD)  (AT&L)  DRAFT  Guide  for 

Contracting  for  Systems  Engineering  (2005) 

Netcentric  Enterprise  Solutions  for  Interoperability  (NESI)  Net-Centric 

Implementation,  Part  6:  Acquisition  Guidance  (2005) 

These  sources  of  guidance  provide  the  users  with  more  detailed  information 
on  the  contracting  aspects  of  using  a  modular  open  systems  approach  to 
contracting.  They  provide  examples,  checklists,  and  recommended  language  for  the 
various  contractual  documents  used  in  the  acquisition  process.  This  research  has 
determined  that  these  sources  are  proving  to  be  very  beneficial  in  helping  develop 
successful  contracts  for  acquisition  programs  using  a  modular  open  systems 
approach. 

Before  proceeding  any  further  with  a  discussion  of  the  contractual 
implications  of  using  an  open  systems  acquisition  approach,  a  distinction  must  be 
made  concerning  the  various  levels  of  applications  of  open  systems.  Care  must  be 
taken  to  ensure  that  any  discussion  of  the  application  of  open  systems  takes  into 
consideration  the  various  reference  points  in  terms  of  the  overall  weapon  system 
structure.  As  weapon  system  technologies  continue  to  advance  and  emerge,  these 
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systems  are  becoming  more  complex  and  complicated;  thus,  it  is  important  to 
identify  the  specific  reference  point  of  discussion.  Weapon  systems  can  be  viewed 
as  containing  four  different  levels — platform,  system,  subsystem,  and  component,  as 
illustrated  in  Figure  4  (US  Navy,  2005,  September  27).  For  example,  open  system 
applications  may  be  discussed  at  the  platform  level  referring  to  the  Littoral  Combat 
Ship  (LCS),  or  at  the  system  level  referring  to  the  sonar  system,  or  at  the  subsystem 
level,  referring  to  the  passive  sonar  subsystem,  or  even  at  the  component  level 
referring  to  the  sonar  data  processor. 


Figure  4.  Open-systems  Approach  Application  Levels 


SUBSYSTEMS 


COMPONENTS 


Source:  Navy  Enterprise  Open  Architecture  Program  Office 
27  September.  2005 
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Roles  and  Responsibilities  during  the  Acquisition  Process 

A  major  consideration  in  developing  the  contracting  strategy  for  an  acquisition 
using  an  open  systems  approach  is  the  determination  of  roles  and  responsibilities  of 
the  buyer  and  the  contractor(s).  The  determination  of  roles  and  responsibilities  will 
have  a  significant  impact  on  the  resulting  contracting  strategy  for  the  acquisition 
program  and  will  most  likely  influence  the  level  of  “openness”  achieved  in  the  design 
and  development  of  the  weapon  system.  This  determination  basically  centers  on  the 
degree  of  control  of  the  requirements — that  is,  the  degree  of  control  of  the  interface 
standards  within  and  between  any  of  the  four  application  levels  (platform,  system, 
subsystem,  component)  and  the  source  of  that  control.  Meyers  and  Oberndorf 
describe  five  different  approaches  to  allocating  roles  and  responsibilities  in  an  open 
systems  acquisition  program  (2001).  These  five  approaches  are  differentiated  by  the 
degree  of  control  allocated  to  the  buyer  and  the  contractor  during  the  selected  steps 
in  the  acquisition  process.  The  selected  steps  in  the  acquisition  process  include 
Specifying  the  Requirements,  Selecting  the  Standards,  Profiling  the  Standards, 
Conducting  Conformance  Qualifications,  Selecting  Standards-based  COTS 
Products,  and  Integrating  the  System.  These  different  approaches  are  labeled  as 
Control,  Direct,  Guide,  Initiate,  and  Joint,  and  reflect  the  varying  degrees  of  control 
between  the  buyer  and  the  contractor.  They  are  illustrated  in  Figure  5  and  described 
below. 
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Figure  5.  Strategies  for  Determining  Roles  and  Responsibilities 
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Source:  Adapted  from  Managing  Software  Acquisition:  Open  Systems  and  COTS 
Products.  Meyers  and  Oberndorf,  Addison-Wesley,  2001. 


On  one  end  of  the  continuum  is  the  Control  strategy.  In  the  Control  strategy, 
the  buyer’s  roles  and  responsibilities  include  specifying  the  system  requirements, 
selecting  the  standards,  profiling  the  standards,  conducting  the  conformance 
qualifications,  and  selecting  the  standards-based  COTS  products.  The  role  of  the 
contractor  is  that  of  the  system  integrator.  Thus,  the  buyer  has  the  most  control 
during  these  select  steps  of  the  acquisition  process. 

In  the  Direct  or  Guide  strategies,  there  is  a  mixture  of  roles  and 
responsibilities  and  a  sharing  of  control  between  the  buyer  and  the  contractor.  In  the 
Direct  strategy,  the  control  of  the  selected  acquisition  steps  is  equally  shared 
between  the  buyer  and  contractor.  The  buyer  specifies  the  system  requirements, 
selects  the  standards,  and  profiles  the  standards.  The  contractor  conducts  the 
conformance  qualifications,  selects  the  standards-based  COTS  products,  and 
performs  as  the  systems  integrator.  In  the  Guide  strategy,  the  control  begins  to  shift 
to  the  contractor.  The  buyer  specifies  the  system  requirements  and 
selects/recommends  the  standards  set,  while  the  contractor  selects  and 
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recommends  the  standards,  profiles  the  standards,  conducts  the  conformance 
qualifications,  and  selects/recommends  the  standards-based  COTS  products,  as 
well  as  performs  as  the  systems  integrator. 

On  the  opposite  side  of  the  continuum  is  the  Initiate  strategy,  where  most  of 
the  control  belongs  to  the  contractor.  The  buyer  specifies  the  requirements,  but  the 
contractor  then  selects/recommends  the  standards,  profiles  the  standards,  conducts 
the  conformance  qualifications,  and  selects/recommends  the  standards-based 
COTS  products,  as  well  as  performs  as  the  systems  integrator. 

A  Joint  strategy  is  also  an  optional  strategy  for  determining  roles  and 
responsibilities  in  the  acquisition  of  open  systems-based  products.  This  strategy  is 
basically  the  application  of  the  Integrated  Product  Team  (IPT)  approach  to  the 
acquisition  process.  In  this  process,  the  roles  and  responsibilities  for  the  acquisition 
steps  are  shared  between  the  buyer  and  contractor  using  IPTs,  with  the  contractor 
ultimately  taking  on  the  role  of  the  systems  integrator  (Meyers  &  Oberndorf,  2001). 
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Contracting  Strategy 


The  Federal  Acquisition  Regulation  (FAR)  Part  34  describes  policy  and 
guidance  for  major  systems  acquisition.  The  FAR  states  that  agencies  acquiring 
major  systems  shall: 

(a)  Promote  innovation  and  full  and  open  competition  as  required  by  Part  6  in 
the  development  of  major  system  concepts  by 

(1)  Expressing  agency  needs  and  major  system  acquisition  program 
objectives  in  terms  of  the  agency’s  mission  and  not  in  terms  of 
specified  systems  to  satisfy  needs,  and 

(2)  Focusing  agency  resources  and  special  management  attention  on 
activities  conducted  in  the  initial  stage  of  major  programs;  and 

(b)  Sustain  effective  competition  between  alternative  system  concepts  and 
sources  for  as  long  as  it  is  beneficial.  (FAR,  34.002) 

Thus,  the  program  acquisition  strategy  should  describe  agency  needs  and 
objectives  using  mission-related  or  performance-based  terms.  In  addition,  the 
contracting  strategy  should  flow  from  the  acquisition  strategy,  and  both  should  be 
consistent  in  goals  and  objectives.  An  acquisition  strategy  using  a  modular  open 
systems  approach  should  be  focused  on  critical  areas  such  as  adopting  evolving 
requirements,  promoting  technology  transfer,  facilitating  system  integration, 
leveraging  commercial  investment,  reducing  cycle-time  and  lifecycle  cost,  ensuring 
interoperability,  enhancing  commonality  and  reuse,  enhancing  access  to  cutting 
edge  technologies  and  products  from  multiple  suppliers,  mitigating  technology 
obsolescence  risk,  mitigating  single  source  of  supply  risk,  enhancing  lifecycle 
supportability,  and  increasing  competition.  Using  a  modular  open  systems  approach 
will  enable  the  acquisition  to  reach  these  objectives  {OSJTF  guide,  2004). 

Therefore,  the  contracting  strategy  supporting  a  MOSA-based  acquisition  strategy 
should  be  structured  to  achieve  these  MOSA  objectives.  This  research  will  discuss 
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how  the  contracting  strategy  should  be  structured  to  achieve  these  MOSA 
objectives. 

As  previously  stated,  the  determination  of  roles  and  responsibilities  has  a 
significant  impact  on  the  resulting  contracting  strategy  for  the  acquisition  program. 
This  determination  of  roles  and  responsibilities  centers  on  the  degree  of  control  of 
the  requirements — that  is,  the  degree  of  control  of  the  interface  standards  within  and 
between  any  of  the  four  application  levels  and  the  source  of  that  control.  We  will 
return  to  this  discussion  on  degree  of  control  on  the  interface  standards,  specifically 
as  it  relates  to  the  contractual  documents  used  in  the  acquisition,  later  in  this 
research  report. 

The  desired  alignment  of  roles  and  responsibilities  in  an  acquisition  program 
using  a  modular  open  systems  approach  should  be  properly  reflected  in  the  various 
contracting  documents  and  contractual  language  developed  during  the  contracting 
process.  The  next  section  of  this  research  will  focus  on  the  various  contractual 
documents  prepared,  contractual  language  developed,  and  contracting  activities 
performed  during  the  acquisition  process,  as  well  as  on  the  implications  of  using  a 
modular  open  systems  approach  on  those  documents,  language,  and  activities. 

This  discussion  will  follow  the  generally  accepted  contracting  process  as  a  construct 
for  discussing  the  contracting  activities  that  are  or  should  be  affected  by  an 
acquisition  pursuing  a  modular  open  systems  approach.  This  contracting  process 
consists  of  the  following  phases — procurement  planning,  solicitation  planning, 
solicitation,  source  selection,  contract  administration,  and  contract  closeout  as 
illustrated  in  Figure  6  (Garrett  &  Rendon,  2005).  Each  of  these  contracting  phases 
will  be  discussed,  along  with  key  practice  activities.  The  implications  for  using  a 
modular  open  systems  approach  will  be  addressed  as  it  relates  to  each  contracting 
phase.  References  will  be  made  to  recent  or  ongoing  acquisition  programs  to 
amplify  the  discussion  of  these  phases. 
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Figure  6.  The  Procurement  Process 


Source:  Adapted  from  Contract  Management:  Organizational  Assess/77e/7f  Toots.  Garrett 
and  Rendon,  NCMA,  2005. 


Procurement  Planning 

Procurement  planning  is  the  first  contracting  phase  and  involves  identifying 
which  business  needs  can  be  best  met  by  procuring  products  or  services  outside  the 
organization.  This  process  involves  determining  whether  to  procure,  how  to  procure, 
what  to  procure,  how  much  to  procure,  and  when  to  procure.  Key  practice  activities 
included  within  the  procurement  planning  phase  include  determining  the  initial  scope 
of  work  or  the  description  of  the  product  in  the  acquisition,  conducting  market 
research  to  analyze  the  level  of  technologies  and  types  of  products  and  services 
available  in  the  marketplace,  determining  funds  availability,  and  developing  initial 
cost  and  schedule  estimates  as  well  as  manpower  resources.  Developing  an  initial 
Statement  of  Work  (SOW)  and  Work  Breakdown  Structure  (WBS)  are  also  included 
in  the  procurement  planning  phase.  Conducting  an  initial  integrated  assessment  of 
contract-type  selection,  risk  management,  and  an  initial  analysis  of  potential  contract 
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terms  and  conditions  is  also  part  of  the  procurement  planning  process  (Garrett  & 
Rendon,  2005).  It  should  be  noted  that  many  of  the  contractual  documents 
developed  in  the  procurement  planning  phase  are  initial  draft  documents,  such  as 
SOWs,  WBSs,  project  scope  statements,  and  funding  and  manpower  estimates. 
These  are  initial  draft  documents  simply  because  they  are  typically  modified  and 
revised  as  the  acquisition  program  office  becomes  more  knowledgeable  of  the 
business  and  technical  aspects  of  the  program.  Industry  business  and  technical 
knowledge  are  typically  acquired  through  the  use  of  market  research  activities, 
industry  conferences,  and  Requests  for  Information  (RFIs). 

Market  Research 

Market  research  is  a  critical  step  in  the  acquisition  of  open  systems-based 
programs.  The  Federal  Acquisition  Regulation  (FAR)  states  that  agencies  must 
conduct  market  research  appropriate  to  the  circumstances  before  developing  new 
requirements  documents  for  an  acquisition  by  that  agency  and  before  soliciting 
offers  for  acquisitions  with  an  estimated  value  in  excess  of  the  simplified  acquisition 
threshold  (FAR  10).  It  is  during  this  process  that  the  buyer  determines  the 
availability  of  COTS  products  and  open  systems-based  products,  as  well  as 
determines  if  these  available  products  will  meet  the  specified  acquisition 
requirements.  Market  research  activities  focus  on  acquiring  knowledge  of  current 
market  practices,  technologies,  capabilities,  products,  and  future  trends  in  areas 
related  to  the  acquisition.  Given  the  objectives  of  using  a  modular  open  systems 
approach,  market  research  is  extremely  critical  in  leveraging  commercial  investment, 
enhancing  access  to  cutting-edge  technologies  and  products  and  increasing 
competition.  Market  research  should  also  be  used  in  an  open  systems-based 
acquisition  to  determine  the  capabilities  of  contractors  to  use  open  systems 
approaches  and  to  comply  with  contractual  requirements  for  using  open  systems 
approaches.  A  market  research  technique  is  the  benchmarking  of  industry  best 
practices  related  to  the  development  and  use  of  open  systems  in  product 
development  (Garrett  &  Rendon,  2005). 
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Industry  Conferences 

Industry  conferences  are  also  used  for  obtaining  industry  knowledge  related 
to  the  development  of  the  solicitation  (as  well  as  the  acquisition  in  general).  Industry 
conferences  can  provide  valuable  information  in  the  areas  of  state  of  technologies 
and  market  practices  concerning  the  use  of  open  systems  and  the  development  of 
open  systems  architectures  in  product  development  and  acquisition.  Industry 
conferences  serve  two  main  purposes — to  inform  industry  about  the  technical 
requirements  and  acquisition  planning  of  the  program  and  to  solicit  industry  inputs 
for  the  pending  program  (Office  of  the  Undersecretary  of  Defense  (AT&L),  2005).  A 
list  of  systems  engineering-related  suggested  topics  for  industry  conferences  is 
provided  in  The  Guide  for  Contracting  for  Systems  Engineering  (Draft)  and  is  found 
in  Appendix  A. 

An  example  of  the  use  of  industry  conferences  is  the  Navy’s  Common 
Enterprise  Display  System  (CEDS)  acquisition  program.  The  Common  Enterprise 
Display  System  (CEDS)  program  establishes  a  family  of  common  display  systems 
that  will  be  implemented  across  platform  systems  on  Navy  surface  ships, 
submarines,  and  aircraft.  CEDS  will  be  designed  to  be  compliant  with  Open 
Architecture  Computing  Environment  (OACE)  requirements  and  will  implement  a 
common  presentation  using  Human  Systems  Integration  (HSI)  design  techniques. 
Through  multi-mission  functionality,  CEDS  will  enhance  survivability  and  re¬ 
configurability  by  allowing  watchstanders  access  to  their  applications  at  any  platform 
display  workstation.  These  CEDS  systems  will  support  Command,  Control, 
Communications,  Computer,  Intelligence,  Surveillance,  and  Reconnaissance 
(C4ISR),  as  well  as  Hull,  Mechanical  and  Electrical  systems  (HM&E)  display 
requirements  (US  Navy,  2005,  September  9c).  The  CEDS  program  conducted  an 
industry  conference  for  the  purpose  of  obtaining  information  from  industry  to  improve 
the  Request  for  Proposal  (RFP)  and  to  provide  information  to  industry  on  the  basic 
requirements  of  the  acquisition  (US  Navy,  2005,  August  30).  The  use  of  the  Industry 
Conference  results  in  increased  and  enhanced  communication  between  the  program 
office  and  interested  offerors.  This  communication  provides  long-term  benefits  to 
the  program  and  greatly  adds  to  the  success  of  the  acquisition. 
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Request  for  Information 

Requests  for  Information  (RFIs)  are  used  as  a  market  research  technique  for 
the  purpose  of  gathering  information  from  industry  to  be  used  in  planning  an 
acquisition.  Government  agencies  typically  use  RFIs  as  a  source  of  information  for 
understanding,  developing,  defining  and  refining  the  acquisition  requirement.  It 
should  be  noted  that  RFIs  are  not  solicitation  notices,  nor  do  they  commit  the 
government  to  issuing  a  solicitation  or  even  continuing  with  the  acquisition.  RFIs  are 
also  used  as  a  method  for  identifying  potential  offerors  for  an  upcoming  acquisition. 
These  types  of  RFIs  are  also  known  as  Sources  Sought  Synopses.  RFIs  typically 
have  the  following  language  as  part  of  the  posted  notice: 

THIS  IS  A  REQUEST  FOR  INFORMATION  ONLY.  The  Government  does  not 
intend  to  award  a  contract  or  any  other  type  of  agreement  on  the  basis  of  this 
synopsis  or  to  otherwise  pay  for  the  information  solicited  under  this  synopsis. 
This  is  NOT  a  request  for  a  proposal  or  an  invitation  for  bid,  merely  a  request 
for  information  only.  The  information  provided  through  the  responses  will  be 
used  to  aid  in  requirements  definition  for  future  acquisitions.  (Appendix  B) 

Given  the  objectives  of  managing  an  acquisition  using  a  modular  open 
systems  approach,  RFIs,  along  with  other  market  research  techniques,  are 
extremely  valuable  for  acquiring  knowledge  of  current  market  practices, 
technologies,  capabilities,  products,  and  future  trends  in  areas  related  to  the 
acquisition.  This  information  will  effectively  support  the  MOSA  objectives  of 
leveraging  commercial  investment,  enhancing  access  to  cutting  edge  technologies 
and  products,  and  increasing  competition.  RFIs  can  be  effective  in  determining  the 
capabilities  of  contractors  to  use  open  systems  approaches  and  to  comply  with 
contractual  requirements  for  using  open  systems  approaches.  RFIs  can  also 
provide  information  on  a  potential  offeror’s  past  performance  in  integrating  technical 
and  management  processes  in  prior  programs  (Office  of  the  Undersecretary  of 
Defense  (AT&L),  2005). 
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An  example  of  an  RFI  is  included  in  Appendix  B.  This  specific  RFI  is  for  the 
purpose  of  determining  the  interest  and  capability  of  industry  for  development  and 
integration  of  an  Anti-Submarine  Warfare  (ASW)/Undersea  Warfare  (USW)  Test 
Information  Management  System.  The  system  will  provide  information 
management,  data  processing,  and  instrumentation  resources.  The  Government  is 
interested  in  obtaining  information  from  industry  to  identify  existing  commercial  off- 
the-shelf  test  information  management  systems,  or  ongoing  or  planned  development 
efforts  for  test  data  modernization  studies.  The  information  provided  through  the 
responses  will  be  used  to  aid  in  requirements  definition  for  future  acquisitions  (US 
Navy,  2004). 

Solicitation  Planning 

The  second  phase  of  the  procurement  process  is  Solicitation  Planning,  which 
involves  the  process  of  preparing  the  solicitation  documents  needed  to  support  the 
acquisition.  This  is  a  critical  phase  of  the  procurement  process  since  it  is  during  this 
phase  that  the  work  statements,  specifications  and  other  exhibits,  standard  terms 
and  conditions,  as  well  as  special  contract  requirements  are  developed,  revised,  and 
finalized.  Key  practice  activities  within  the  solicitation  planning  process  include 
using  standard  procurement  forms  and  documents  such  as  solicitation  templates, 
model  contracts,  specifications  and  item  descriptions,  solicitation  provisions,  and 
contract  terms  and  conditions  (Garrett  &  Rendon,  2005).  Federal  Acquisition 
Regulations  (FAR)  require  contracting  officers  to  prepare  solicitations  and  contracts 
using  the  FAR-specified  uniform  contract  format  to  the  maximum  extent  possible,  as 
well  as  the  required  solicitations  provisions  and  contract  clauses.  Figure  7  provides 
a  description  of  the  FAR  Uniform  Contract  Format. 
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Figure  7.  Uniform  Contract  Format 


Part  /  —  The  Schedule 

A  Solicitation/contract  form. 

B  Supplies  or  services  and 
prices/costs. 

C  Description/specifications/ 
statement  of  work. 

D  Packaging  and  marking. 

E  Inspection  and  acceptance. 

F  Deliveries  or  performance. 

G  Contract  administration  data. 

H  Special  contract  requirements. 


Part  II  —  Contract  Clauses 

I  Contract  clauses. 


Source:  Federal  Acquisition  Regulation.  15.204-1 


Part  III  —  List  of  Documents,  Exhibits, 
and  Other  Attachments 


Part  IV  —  Representations  and 
Instructions 

K  Representations,  certifications,  and  other 
statements  of  offerors  or  respondents. 

L  Instructions,  conditions,  and  notices 
to  offerors  or  respondents. 

M  Evaluation  factors  for  award. 


J  List  of  attachments. 


The  solicitation  for  an  acquisition  program  using  an  open  systems  approach 
will  require  specific  language  unique  to  the  use  of  a  modular  open  systems 
approach.  Thus,  the  procurement  documents  that  make  up  the  solicitation  should 
incorporate  the  specific  language  that  reflects  the  preference  or  mandated  use  of  a 
modular  open  systems  approach  in  the  acquisition  program.  Section  C 
(Description/Specification/Statement  of  Work),  Section  L  (Instructions,  Conditions, 
and  Notices  to  Offerors  or  Respondents),  and  Section  M  (Evaluation  Factors  for 
Award)  are  the  primary  parts  of  the  solicitation  that  are  influenced  by  the  particular 
engineering  approach  to  the  acquisition  program.  These  sections  are  the  core  of  the 
solicitation  and  directly  influence  the  offeror’s  proposal  and  the  resulting  contract,  as 
illustrated  in  Figure  8  (Office  of  the  Undersecretary  of  Defense  (AT&L),  2005). 
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Figure  8.  Engineering  Influences  the  Major  Elements  of  the  RFPs 
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System 
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Applicable 

Documents 
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CLIIMS 


Source:  Draft  Guide  to  Contracting  for  Systems  Engineering.  2005. 


It  is  the  documents  in  this  section  that  will  be  most  effective  in  communicating 
the  government’s  requirements  for  using  an  open  systems  approach  in  the 
acquisition.  Thus,  acquisitions  that  are  using  a  modular  open  systems  approach 
should  have  specific  and  unique  documents  and  language  within  these  solicitation 
sections  and  documents.  The  procurement  documents  and  specific  solicitation 
language  that  will  be  discussed  in  this  solicitation  planning  phase  include  Section  C 
documents  such  as  the  Statement  of  Objective  (SOO)/Statement  of  Work  (SOW) 
and  Preliminary  System  Specification,  and  Section  L  documents  which  consist  of  the 
Instruction  to  Offerors  (ITOs).  The  discussion  of  the  Source  Selection  phase  of  the 
contracting  process  will  address  Section  M,  Evaluation  Factors  for  Award. 

Section  C  of  the  solicitation  consists  of  descriptions,  specifications,  and 
statements  of  work  for  the  acquisition  program.  This  section  of  the  solicitation 
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contains  the  detailed  description  of  the  products  to  be  delivered  or  the  work  to  be 
performed  under  the  contract. 

System  Performance  Specification 

A  critical  Section  C  document  is  the  performance  specification.  The  system 
performance  specification  defines  the  government’s  performance  requirements  for 
the  system  and  should  reference  any  industry  and  approved  military  specifications 
and  standards.  Typically,  the  system  performance  specification  in  the  solicitation  is 
considered  a  “preliminary  system  performance  specification,”  and  the  offeror 
responds  to  the  solicitation  with  a  formal  system  performance  specification  in  its 
proposal.  The  solicitation  must  be  clear  in  delineating  whether  the  government  will 
consider  offeror-proposed  revisions  to  the  preliminary  performance  requirements 
that  may  be  cost  effective.  The  offerors  run  the  risk  of  being  declared  non- 
responsive  to  the  solicitation  for  proposing  revised  performance  requirements  (Office 
of  the  Undersecretary  of  Defense  (AT&L),  2005).  In  acquisition  programs  using  a 
modular  open  systems  approach,  the  system  performance  specification  plays  a 
critical  role  in  communicating  the  government’s  requirement  for  communicating 
“openness”  and  delineating  requirements  for  open  systems.  Typically,  the 
performance  specification  is  developed  using  the  requirements  document  that  was 
the  basis  for  initiating  the  acquisition.  These  requirements  documents,  such  as  the 
Operational  Requirements  Documents  (ORD)  or  Capability  Development  Document 
(ODD),  will  be  extensively  used  in  developing  the  performance  specification.  An 
example  of  the  relationship  between  the  requirements  documents  (ORD/CDD)  and 
the  system  performance  specification  is  found  in  the  Multi-Mission  Maritime  Aircraft 
(MMA)  Program.  The  Navy’s  MMA  is  the  replacement  for  the  P-3C  Orion  with 
primary  roles  of  antisubmarine  and  antisurface  warfare.  The  MMA  is  one  element  of 
the  Navy’s  Broad  Area  Maritime  Surveillance  (BAMS)  family  of  systems,  along  with 
the  BAMS  Unmanned  Aerial  Vehicle  (UAV)  and  Aerial  Common  Sensor  programs. 
The  MMA  is  manned,  and  it  will  sustain  and  improve  armed  maritime  and  littoral 
intelligence  surveillance  and  reconnaissance  capabilities  of  the  US  Navy  (GAO, 
2005,  March  31). 
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Figure  9.  Linking  OA  Poiicy  to  Contractuai  Documents 


I  I  Contractually  Binding 


Source:  Adapted  from  NAVAIR  briefing  presented  at  Naval  Enterprise  Open 
Architecture  Contracts  Symposium,  29  September  2005. 


As  Figure  9  illustrates,  the  language  from  DoD  5000.1  and  the  OSJTF  MOSA 
Guide  influenced  the  open  systems  language  in  ORD/CDD.  The  ORD/CDD 
language  influenced  the  development  of  the  MMA  Performance-based  System 
Specification  (PBSS),  which  was  then  decomposed  into  the  multiple  requirements 
that  are  on  contract.  The  Contractor  then  decomposed  those  requirements  into 
segment  specification. 

Figure  10  illustrates  the  open  systems  language  that  was  used  in  the  MMA 
ORD/CDD  and  the  related  open  systems  requirements  listed  in  the  Performance- 
based  System  Specifications  (PBSS)  and  the  relation  of  the  PBSS  to  the  lower  level 
segment  specification  developed  by  the  contractor. 
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Figure  10.  MMA  Open  Systems  Requirements 
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"The  initial  production  block  of  MMA  will  have  an  open  system  core 
architecture  capable  of  incorporating  future  upgrades  to  sensors, 
processing,  displays,  communications,  navigation,  self-protection 
and  stores  management  (Threshold).  The  MMA  hardware  and 
software  architecture  will  be  sufficiently  modular  and  scalable  to 
readily  and  affordably  allow  for  technology  insertion  and 
functionality  improvement.  MMA  will  have  adequate  design  weight 
margins  to  allow  for  avionics  system  growth.  In  addition,  MMA  will 
provide  growth  provisions  for  increased  power  and  environmental 
control  capacities.” 


[REQUID-4900] 

[REQUID-4910] 

[REQUID-4990] 

[REQUID-5000] 

[REQUID-5020] 

[REQUID-5030] 

Encap 

[REQUID-5060] 


MMA  Mission  System  Qpen  Systems  Approach 
MS  Architecture  facilitating  COTS/NDI  use 
MS  Architecture  Attributes 
Qpenness 

Scalability  and  Evolvability 

MMA  Mission  Systems  Physical  Integration/Fxn 

Information  Assurance  and  Protection 


System  specification  requirements  map  directly  to  PBS 
requirements 


Source:  Adapted  from  NAVAIR  briefing  presented  at  Naval  Enterprise  Open  Arohiteoture  Contraots  Symposium, 
29  September  2005. 


Statement  of  Work 

Another  critical  document  in  Section  C  of  the  Solicitation  is  the  Statement  of 
Work  (SOW).  Traditionally,  the  government  has  used  a  SOW  in  its  major  acquisition 
programs.  The  solicitation  Statement  of  Work  (SOW)  describes  the  actual  work  to 
be  done  by  means  of  specifications  or  other  minimum  requirements,  quantities, 
performance  date,  and  requisite  quality  (Garrett  &  Rendon,  2005).  The  offerors 
propose  their  management,  technical,  and  cost  approach  to  meeting  the 
requirements  of  the  SOW  in  their  proposal.  Already  a  critical  part  of  the  solicitation 
package,  the  SOW  takes  on  even  more  of  a  significant  role  in  an  acquisition  using 
an  open  systems-based  approach.  In  these  acquisition  programs,  the  SOW  must 
be  clear  and  concise  in  communicating  the  requirements  that  contractors  must 
comply  with  in  terms  of  meeting  open  systems  standards  and  incorporating  open 
system  components  in  the  development  of  the  total  system. 
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Referring  once  again  to  the  Navy’s  Common  Enterprise  Display  System 
(CEDS)  Program,  the  CEDS  SOW  provides  an  excellent  example  of  effective 
language  related  to  the  use  of  an  open  systems-based  acquisition  approach. 
Appendix  C  reflects  an  extract  from  the  CEDS  SOW,  specifically  referring  to  the  use 
of  open  systems  and  a  modular  open  systems  approach.  SOW  3. 1.3. 2  language 
specifically  communicates  the  contractor’s  requirement  to  comply  with  the  PEO  IWS 
Open  Architecture  Computing  Environment  Design  Guidance,  PEO  IWS  Open 
Architecture  Computing  Environment  Technologies  and  Standards,  and  the  PEO  C4I 
Rapid  Application  Integration  and  Development  Standards  in  the  development  of  the 
CEDS  equipment.  Thus,  the  SOW  is  clear  and  exact  in  describing  the  contractor’s 
requirement  to  comply  with  the  specific  open  architecture  guidance  documents.  It 
should  be  noted  that  the  SOW  refers  to  these  specific  documents:  PEO  IWS  Open 
Architecture  Computing  Environment  Design  Guidance,  PEO  IWS  Open  Architecture 
Computing  Environment  Technologies  and  Standards,  and  the  PEO  C4I  Rapid 
Application  Integration  and  Development  Standards  (US  Navy,  2005,  September 
9c). 


CEDS  SOW  3.1 .3.3  also  requires  the  contractor  to  use  a  modular  open 
systems  approach  in  implementing  a  modular  design  strategy  for  building  the  system 
and  refers  to  the  Under  Secretary  of  Defense  Memorandums:  Amplifying  DoDD 
5000. 1  Guidance  Regarding  Modular  Open  Systems  Approach  (MOSA) 
Implementation  and  Instructions  for  Modular  Open  Systems  Approach  (MOSA) 
Implementation.  This  section  of  the  SOW  specifically  tells  the  contractor  that  a 
primary  consideration  in  selection  of  equipment  shall  be  the  impact  to  the  overall 
modular  open  systems  architecture.  Additionally,  the  SOW  stresses  the  importance 
of  long-term  supportability,  interoperability,  and  growth  for  future  modifications  as 
major  factors  in  the  contractor’s  selection  of  equipment.  Furthermore,  the  SOW  is 
specific  in  requiring  the  contractor  to  use  an  architectural  approach  that  will  provide 
a  viable  technology  insertion  methodology  and  refresh  strategy  as  well  as  to 
maximize  commonality  of  components  used  in  the  CEDS  equipment  across  all 
product  baselines.  Finally,  the  contractor  is  required  to  develop  metrics  to  measure 
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the  degree  of  success  in  achieving  the  commonality  goals  (US  Navy,  2005, 
September  9c). 

The  Littoral  Combat  Ship  (LCS)  Mission  Package  Integrator  contract  in 
support  of  the  LCS  Mission  Module  program  is  another  example  of  incorporating 
open-systems-related  language  into  the  SOW.  The  Navy’s  Littoral  Combat  Ship  is 
to  be  a  fast,  maneuverable,  shallow  draft,  surface  combatant  optimized  for  littoral 
warfare.  LCS  will  employ  innovative  hull  designs  and  reconfigurable  mission 
packages  to  counter  anti-access  threats  in  three  mission  areas:  mine, 
antisubmarine,  and  surface  warfare  (GAO,  2005,  March  31).  SOW  paragraph 
3.1.1 .2,  under  the  Requirements  section  of  the  SOW,  states  that  the  Contractor  shall 
propose  a  process  for  identifying  and  selecting  new  technologies  for  inclusion  in 
future  Mission  Package  spirals.  Specifically,  the  SOW  states  the  following: 

Four  principles  which  shall  be  inherent  in  developing  this  process  are  1)  the 
practice  of  including  all  applicable  foreign  and  domestic  governments,  industry  and 
academia,  in  the  search  for  new  technology  candidates,  and  technology  projection 
2)  employment  of  Open  Systems  Architecture  (OSA)  modularity  and  industry 
standards,  3)  the  inclusion  of  a  Mission  Package  Decision  Board  (MPDB),  under  the 
leadership  of  PMS  420,  for  selecting  material  solutions  for  inclusion  in  spirals,  and  4) 
the  capture  and  inclusion  of  Fleet  input  (US  Navy,  2005,  June). 

Also  stated  in  the  SOW,  under  paragraph  3.1.2,  Mission  Package 
Development,  Engineering,  Integration,  Test  &  Evaluation  and  Certification  Support 
Agent,  all  contractor-developed  software  shall  be  open  source  to  the  government 
and  all  other  activities,  and  that  the  contractor  shall  design  and  develop  a  hardware 
baseline  for  the  Mission  Package  Computing  Environment  (MPCE),  which  complies 
with  the  Navy  open  architecture  requirements  to  support  all  Mission  Package 
configurations.  Appendix  D  provides  an  extract  of  the  LCS  Mission  Package 
Integrator  SOW  (US  Navy,  2005,  June). 

As  can  be  seen,  the  SOW  in  solicitations  and  resulting  contracts  for 
acquisition  programs  using  an  open  systems  approach  is  a  critical  tool  for 
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delineating  the  contractor’s  requirements  and  responsibilities  in  performing  the 
contract. 

Statement  of  Objectives 

With  the  continued  emphasis  on  Acquisition  Reform  and  the  streamlining  of 
the  acquisition  process,  many  government  agencies  are  now  using  a  Statement  of 
Objectives  (SOO)  instead  of  a  SOW  in  the  solicitation.  The  SOO  is  a  government- 
prepared  document  incorporated  into  the  RFP  that  states  the  overall  objectives  of 
the  solicitation.  Typically,  the  SOO  is  a  very  short  document,  usually  under  10 
pages,  that  clearly  delineates  the  program  objectives  and  the  overall  program 
approach  of  the  acquisition.  The  purpose  of  the  SOO  is  to  provide  the  maximum 
flexibility  to  each  offer  to  propose  an  innovative  development  approach  (Garrett  & 
Rendon,  2005).  The  offerors  respond  to  the  government’s  SOO  with  a  SOW 
providing  the  details  of  its  proposed  management,  technical,  and  cost  approach  for 
delivering  the  requirements  of  the  acquisition.  Therefore,  instead  of  the  government 
developing  the  SOW  with  detailed  instructions  and  requirements,  the  government 
provides  the  SOO  with  only  the  top  level  objectives  of  the  acquisition;  the  offerors 
then  respond  with  the  proposed  detailed  approach  in  their  SOW.  Thus,  the  use  of 
the  SOO  by  the  government  encourages  offerors  to  propose  innovative  approaches 
and  flexible  design  solutions  (Meyers  &  Oberndorf,  2001).  With  this  in  mind,  it  can 
be  clearly  seen  how  SOOs  definitely  support  the  use  of  a  modular  open  systems 
approach  acquisition  program. 

Referencing  the  Multi-Mission  Maritime  Aircraft  program  and  Figure  9  again, 
one  can  see  how  the  DoD  5000.1  and  the  OSJTF  MOSA  Guide  language  was  used 
in  the  MMA  System  Development  and  Demonstration  (SDD)  solicitation,  which 
contained  a  Statement  of  Objectives  (SOO),  and  the  Contractor  responded  with  a 
Statement  of  Work  in  its  proposal,  with  the  finalized  SOW  becoming  contractually 
binding  in  the  contract.  Figure  11  illustrates  the  MOSA  language  used  in  the  MMA 
SOO  and  reflected  in  the  contractor’s  contractually  binding  SOW.  It  should  be  noted 
that  the  MMA  SOO  open  systems  language  was  adapted  from  the  OSJTF  MOSA 
Guide.  The  SOO  supports  MOSA  objectives  of  leveraging  commercial  investment. 
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enhancing  access  to  cutting-edge  technologies  and  products  from  multiple  suppliers, 
and  increasing  competition  (US  Navy,  2005,  September  29b).  The  OSJTF  Guide 
provides  examples  of  MOSA-related  objectives  that  would  be  appropriate  for  SOOs 
as  a  method  for  conveying  the  main  objectives  of  the  acquisition.  These  are  listed  in 
Appendix  E. 


Figure  11.  MMA  Open-systems  Contract  Documents 
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Statement  of  Objectives 
Section  J  -  Attch  2 


Statement  of  Work 
(Contractually  Binding) 
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Facilitate  development  of  a  modular  architecture  and 
aiiow  for  affordable  intraoperability. 

Ensure  that  the  system  design  is  sufficientiy  flexibie  and 
robust  to  accommodate  changing  technoiogy  and 
requirements 

Faciiitate  integration  with  other  systems  and  use  of 
commercial  products  from  multiple  sources  both  in  the 
initiai  design  and  in  future  enhancements 

Enabie  technoiogy  insertion  as  currentiy  avaiiabie 
commercial  products  mature  and  new  commercial 
products  become  available  in  the  future 

Aiiow  for  affordabie  support 

Aiiow  continued  access  to  technologies  and  products 
supported  by  many  suppliers  (a  broad  industriai  base 
which  does  not  restrict  available  sources  to  the  detriment 
of  competition) 

System  design  enables  technology  insertion  as  currentiy 
avaiiabie  commercial  products  mature  and  new 
commercial  products  become  available  in  the  future 

Enable  incremental  system  improvements  through 
upgrades  of  individual  hardware  or  software  modules 
with  newer  moduiar  components  without  redesign  of 
entire  systems  or  iarge  portions  thereof 

Mitigate  the  risks  associated  with  technoiogy 
obsoiescence" 


Source:  Adapted  from  NAVAIR  briefing  presented  at  Naval  Enterprise  Open  Architecture  Contracts  Symposium,  29 
September  2005. 


Contract  Data  Requirements  List  (CDRL) 

Another  critical  document  in  the  solicitation  is  the  Contract  Data 
Requirements  List  (CDRL),  DD  Form  1423.  The  CDRL  is  a  list  of  all  authorized  data 
requirements  for  a  specific  procurement  that  forms  a  part  of  the  contract.  CDRLS 
should  be  linked  directly  to  the  required  tasks  in  the  Statement  of  Work  (SOW) 
(Office  of  the  Undersecretary  of  Defense  (AT&L),  2005).  In  relation  to  open  systems 
and  using  an  open  systems  approach  in  the  acquisition,  the  government  can  request 
certain  data  or  even  demonstrations  from  the  contractor,  as  part  of  the  contract 
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performance  requirements.  Referring  back  to  the  Navy  CEDS  program,  CDRLs  are 
being  used  to  require  the  contractor  to  obtain  government  approval  of  its  proposed 
open  systems  profile  for  each  CEDS  configuration.  The  CDRL  requires  that  the 
contractor’s  open  systems  profile  be  revised  for  each  technology  to  reflect  the 
obsolescence/infusion  change  as  it  affects  the  external  or  internal  interfaces  of  the 
product  baseline.  Appendix  F  provides  an  extract  from  a  CDRL  (US  Navy,  2005, 
September  9a). 

The  Multi-Mission  Maritime  Aircraft  (MMA)  Program  made  excellent  use  of 
CDRLs  when  it  required  the  contractor  to  demonstrate  the  “openness”  of  its  mission 
suite  prototype  that  it  constructed  during  the  Component  Advancement  Development 
phase  of  the  acquisition.  During  the  demonstration,  the  contractor  was  required  to 
show  how  its  mission  suite  prototype  complied  with  open  architecture  principles  in 
response  to  various  scenarios  that  challenged  the  openness  of  the  system.  This 
demonstration  requirement,  using  the  CDRL,  was  effective  in  ensuring  that  the 
openness  requirements  were  being  flowed  down  to  the  lower  subsystems  (US  Navy, 
2005,  September  29b). 

Instructions  to  Offerors 

In  addition  to  the  documents  in  Section  C  of  the  Solicitation,  such  as  the 
System  Performance  Specification,  SOO/SOW,  and  CDRL,  specific  language  should 
also  be  included  in  Section  L  of  the  solicitation  as  well.  Section  L  provides  the 
Instructions  to  the  Offerors  (ITOs)  for  developing  the  proposals  in  response  to  the 
solicitation. 

Section  L  of  the  solicitation  specifies  the  format  and  content  of  proposals,  as 
well  as  information  or  proposal  preparation  instructions  that  are  not  included 
elsewhere  in  the  solicitation  (Engelbeck,  2002).  Acquisitions  using  a  modular  open 
systems  approach  have  a  critical  need  for  providing  specific  instructions  to  offerors 
concerning  the  development  of  proposals  and  the  offeror’s  adherence  to  the  use  of 
open  systems  in  the  development  process.  Typically,  the  ITOs  reference  other 
documents  in  the  solicitation  package  such  as  system  technical  architecture 
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requirements  and  design  guidance  and  standards  for  open  architectures.  The  ITO 
typically  specifies  the  factors  to  be  used  in  the  proposal  evaluation  phase  of  the 
source  selection.  These  evaluation  factors  are  traditionally  categorized  as  technical, 
cost,  and  management.  In  acquisitions  using  a  modular  open  systems  approach, 
usually  the  technical  evaluation  factor  specifies  the  ITO  requirements  related  to  the 
acquisition’s  open-systems  requirements. 

An  example  of  an  ITO  language  for  an  open-systems-based  acquisition  is 
found  in  the  Section  L  of  the  Littoral  Combat  ship  (LOS)  Flight  0  Preliminary  Design 
solicitation  (US  Navy,  2003).  The  LOS  ITO  is  divided  into  three  parts — 
administrative  requirements,  technical  volume  requirements,  and  price  volume 
requirements.  The  language  specific  to  meeting  the  program’s  open  systems 
requirements  are  found  in  Part  II,  Technical  Volume  Requirements,  under  System 
Architecture  Development  and  Implementation  Approach.  In  this  part  of  the  RFP’s 
ITO,  the  prospective  contractor  is  required  to  present  its  understanding  of  the  scope 
and  overall  approach  to  providing  the  required  effort.  It  is  interesting  to  note  that  the 
LOS  solicitation  requires  the  offeror’s  technical  proposal  to  include  a  matrix  that 
shows  traceability  from  the  specific  requirements  of  Section  L  to  the  offeror’s 
technical  proposal.  Appendix  G  reflects  an  extract  from  the  LCS  Instructions  to 
Offerors,  referring  to  the  use  of  open  systems  and  a  modular  open  systems 
approach.  Specifically  in  terms  of  meeting  the  open  systems  approach 
requirements,  the  LCS  ITO  requires  the  offeror  to  describe  its  approach  for 
developing  and  implementing  a  wide  use  of  open  systems  for  mission  module 
interfaces,  C4I  systems,  FORCEnet  and  FIM&E  systems  in  accordance  with  the 
Design  Guidance  For  The  Navy  Open  Architecture  Computing  Capability,  the  Navy 
Open  Architecture  Computing  Environment  Technologies,  Standards  and  Products, 
and  the  Mission  System  Technical  Architecture  Requirements  (US  Navy,  2003). 

Solicitation 

Solicitation  is  the  third  phase  of  the  procurement  process  and  is  the  process 
of  obtaining  bids  and  proposals  from  prospective  sellers  on  how  to  meet  the 
objectives  of  the  project.  The  solicitation  phase  is  critical  to  the  overall  acquisition 
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strategy  because  it  is  this  phase  that  executes  the  procurement  planning  strategy  for 
a  full  and  open  competition  or  a  sole  source  procurement.  Some  key  practice 
activities  within  the  Solicitation  phase  include  conducting  market  research  and 
advertising  to  identify  new  sources  of  supplies  and  services  for  the  purpose  of 
developing  a  list  of  interested  offerors  (Garrett  &  Rendon,  2005).  These  offerors  will 
receive  the  solicitation  requesting  the  proposal.  Another  key  practice  activity  in  the 
Solicitation  phase  includes  conducting  a  pre-solicitation  or  pre-proposal  conference 
to  ensure  that  all  prospective  contractors  have  a  clear,  common  understanding  of 
the  technical  and  contractual  requirements  of  the  acquisition  (Garrett  &  Rendon, 
2005).  In  this  section  on  the  Solicitation  process,  the  use  of  Draft  RFPs  during  the 
solicitation  process  and  the  implications  of  using  a  full  and  open  competition  or  a 
sole  source  procurement  strategy  for  open  systems-based  acquisitions  will  be 
discussed. 

Draft  RFPs 

Typically,  the  process  of  issuing  a  solicitation  and  then  later  amending  the 
solicitation  to  incorporate  corrections,  updated  specifications,  and  revised  language 
results  in  an  extended  and  prolonged  acquisition  schedule.  One  of  the  goals  of  the 
solicitation  process  is  to  develop  and  structure  a  current  and  complete  solicitation 
that  will  result  in  accurate,  complete,  and  competitive  proposals  from  prospective 
contractors  in  the  shortest  amount  of  time.  The  use  of  Draft  RFPs  has  become  a 
proven  best  practice  in  the  solicitation  planning  process  (Garrett  &  Rendon,  2005). 
Issuing  a  Draft  RFP  to  interested  offerors  allows  for  additional  industry  feedback  on 
any  aspect  of  the  proposed  acquisition.  With  this  “early  and  up-front”  feedback  from 
interested  offerors  to  the  contracting  office,  the  contracting  office  can  continue  to 
improve  and  enhance  the  solicitation  while  it  is  still  being  developed,  thus  saving 
time  and  shortening  the  acquisition  schedule.  Referring  back  to  the  CEDS  program, 
the  CEDS  program’s  use  of  a  Draft  RFP  reflects  this  best  practice  in  the  solicitation 
planning  process.  The  CEDS  program  office  issued  a  Draft  RFP  that  was  posted  to 
the  program  office  website.  The  Draft  RFP  consisted  of  Sections  B  through  M,  and 
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the  interested  offerors  were  given  a  21 -day  period  to  review  and  provide  comments 
back  to  the  program  office  (US  Navy,  2005,  August  30). 

Procurement  Strategy 

In  developing  a  procurement  strategy  for  an  acquisition  program,  the 
traditional  options  include  conducting  a  full  and  open  competition  or  a  sole  source 
procurement.  Statutory  requirements,  specifically  10  U.S.C.  2304  and  41  U.S.C. 

253,  require  that  contracting  officers  promote  and  provide  for  full  and  open 
competition  in  soliciting  offers  and  awarding  contracts  (FAR,  6.101).  There  are 
certain  statutory  authorities  permitting  contracting  without  providing  for  full  and  open 
competition  (sole  source),  as  discussed  in  FAR  6.302.  The  benefit  of  full  and  open 
competition  includes  obtaining  quality  goods  and  services  at  a  fair  and  reasonable 
price.  Allowing  all  responsible  offerors  to  compete  also  allows  the  government  to 
leverage  the  forces  of  the  marketplace  to  include  leading  technologies  and 
innovative  management  approaches  in  developing  solutions.  Obviously,  the  benefits 
of  pursuing  a  full  and  open  competition  fully  support  the  objectives  of  managing  an 
acquisition  program  using  an  open  systems  approach.  Since  the  underlying 
concepts  of  an  open  systems-based  acquisition  focus  on  the  ability  to  insert  cutting- 
edge  technology  as  it  evolves,  the  commonality  and  reuse  of  components  among 
systems,  the  enhanced  access  to  emerging  technologies  and  products  from  multiple 
suppliers,  the  increased  ability  to  leverage  commercial  investment,  and  an  increase 
in  competition,  it  would  seem  appropriate  to  pursue  a  full  and  open  competition 
strategy  for  the  acquisition.  It  should  be  noted  that  in  some  cases,  especially  at  the 
platform  level,  the  use  of  a  full  and  open  competition  strategy  is  not  possible. 

The  acquisition  of  the  Virginia  Class  Submarine  is  an  example  of  the  need  for 
other  than  full  and  open  competition  strategies. 

A  unique  procurement  strategy  is  the  use  of  a  “rolling  down-select” 
procurement  strategy  approach.  In  this  approach,  a  full  and  open  competition  is 
initially  conducted,  and  multiple  contracts  are  awarded.  These  contracts  are 
typically  used  early  in  the  acquisition  lifecycle,  such  as  for  the  development  of 
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preliminary  designs.  Once  the  designs  have  been  submitted  and  evaluated,  a  down- 
select  of  the  initial  contractors  to  a  single  contractor  is  conducted  for  the 
development  and  production  of  the  actual  system.  The  acquisition  strategy  may 
involve  multiple  “down-selects,”  depending  on  how  many  evaluation  phases  the 
buyer  desires.  For  example,  there  may  be  an  initial  full  and  open  competition  for 
conceptual  development  contracts,  a  down-select  to  a  smaller  number  of  the  original 
contractors  for  preliminary  designs,  another  down-select  to  even  a  smaller  number 
of  contractors  for  prototype  development,  and  finally,  a  final  down-select  to  a  single 
contractor  for  full  development  and  production  of  the  actual  system. 

A  version  of  this  down-select  strategy  is  used  by  the  Navy’s  Common 
Enterprise  Display  System  (CEDS)  acquisition  program.  According  to  the  CEDS 
acquisition  strategy,  the  program  will  be  divided  into  two  phases.  Phase  1  will  be  for 
the  Preliminary  design,  and  Phase  2  will  be  for  the  Development,  Qualification,  and 
Production.  Both  of  these  phases  will  apply  to  the  Display  Consoles  (DC)  and 
Remote  Display  (RD)  systems.  The  Phase  1  strategy  will  consist  of  an  initial  full  and 
open  competition  strategy  resulting  in  up  to  four  awarded  contracts — two  for  the  DC 
and  two  for  the  RD  systems.  The  award  criteria  for  the  Phase  1  contracts  include 
Management  Approach,  Capability  to  Execute,  Past  Performance,  and  Cost.  Based 
on  a  best  value  evaluation  contract  award  strategy,  the  deliverables  for  this  contract 
include  a  Preliminary  Design  of  the  system  and  a  successful  Preliminary  Design 
Review  (PDR),  as  well  as  estimated  Lifecycle  Costs,  and  a  cost  and  technical 
proposal  for  the  Phase  2  part  of  the  acquisition.  The  Phase  2  portion  of  the 
acquisition  will  be  limited  to  only  the  initial  contractors  that  successfully  completed 
the  Phase  1  requirements.  Phase  2  will  consist  of  a  contract  award  each  for  the  DC 
and  the  RD  systems,  with  a  best-value  award  based  on  the  technical  approach 
presented  at  the  PDR,  management,  technical,  and  production  capability,  among 
other  factors.  After  a  successful  Production  Readiness  Review,  the  production 
Contract  Line  Item  Numbers  (CLINs)  will  be  exercised  to  execute  the  production 
portion  of  Phase  2  (US  Navy,  2005,  August  30). 
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The  Multi-Mission  Maritime  Aircraft  (MMA)  also  used  a  rolling,  down-select 
type  of  procurement  strategy.  During  the  MMA  Component  Advanced  Development 
(CAD)  contract  phase  of  the  acquisition,  the  result  was  a  competitive  source 
selection,  with  contract  awards  to  Boeing  and  Lockheed  Martin.  Boeing  had 
proposed  its  737  Next  Generation,  and  Lockheed  Martin  had  proposed  its  Orion  21 . 
After  the  Milstone  B  review,  the  System  Development  and  Demonstration  contract 
was  awarded  to  Boeing  (US  Navy,  2005,  September  29b). 

As  previously  stated,  the  benefits  of  pursuing  a  full  and  open  competition  fully 
support  the  objectives  of  using  an  open  systems  approach  in  an  acquisition 
program.  Opening  the  acquisition  to  allow  all  qualified  offerors  to  participate  enables 
the  government  to  enhance  access  to  cutting-edge  technologies  and  products  from 
multiple  suppliers,  to  have  the  ability  to  insert  cutting-edge  technology  as  it  evolves, 
and  to  have  the  increased  ability  to  leverage  commercial  investments  in  technology. 
Of  course,  at  some  point  in  time,  the  government  will  need  to  establish  a  relationship 
with  one  contractor;  otherwise  having  multiple  contractors  producing  the  same 
system  may  be  cost  prohibitive.  The  major  issue  is  determining  how  many  contracts 
to  award  following  a  full  and  open  competition  and  how  to  structure  the  “down- 
select”  process  to  determine  the  single  production  contractor. 

Source  Selection 

Source  Selection  is  the  fourth  phase  of  the  contracting  process  and  involves 
the  process  of  receiving  proposals  and  applying  evaluation  criteria  to  select  the 
contractor.  Key  practice  activities  within  the  source-selection  process  include  using 
evaluation  criteria  focusing  on  management,  technical,  and  cost,  tailoring  the  basis 
for  award  to  either  lowest  cost/technically  acceptable  or  best  value,  and  taking  into 
consideration  an  offeror’s  past  performance  in  evaluating  proposals  (Garrett  & 
Rendon,  2005). 

Evaluation  Factors 

Section  M  of  the  solicitation  specifies  how  the  buyer  will  evaluate  the  factors 
identified  in  the  Instructions  to  Offerors  (ITO)  in  Section  L.  As  previously  stated. 
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Section  L  specifies  the  factors  to  be  used  in  the  proposal  evaluation  phase  of  the 
source  selection,  while  Section  M  specifies  how  the  factors  will  be  used  in  the 
proposal  evaluation  process.  These  evaluation  factors  are  traditionally  categorized 
as  technical,  cost,  and  management.  In  acquisitions  using  a  modular  open  systems 
approach,  it  is  usually  the  technical  evaluation  factor  that  specifies  the  ITO 
requirements  related  to  the  acquisition’s  open  system  requirements.  The 
relationship  between  cost  and  non-cost  factors  (such  as  quality,  technical,  and  past 
performance),  as  well  as  how  they  will  be  used  in  the  source-selection  decision,  are 
described  in  Section  M.  The  two  major  evaluation  strategies  are  Lowest 
Price/Technically  Acceptable  (LPTA)  or  best  value.  Best  value  refers  to  an 
evaluation  strategy  where  trade-offs  are  made  in  relation  to  cost  and  other  factors. 
Thus,  in  an  LPTA  source  selection,  the  offeror  proposing  the  lowest  price,  technically 
acceptable  offer  will  be  awarded  the  contract.  However,  in  a  best-value  source 
selection,  the  contract  award  may  be  made  to  “other  than  the  lowest  priced, 
technically  acceptable  offeror,”  based  on  a  trade-off  among  cost,  technical,  and  past 
performance  factors.  It  is  important  that  the  proposal  evaluation  strategy  should  be 
tailored  to  meet  the  objectives  of  the  acquisition  strategy  (Garrett  &  Rendon,  2005). 
The  use  of  the  best-value  evaluation  strategy  is  appropriate  for  acquisitions  that 
involve  requirements  that  are  less  definitive,  require  more  development  work,  or  the 
acquisition  has  greater  performance  risk,  and  where  more  technical  or  past 
performance  considerations  play  a  dominant  role  in  the  source-selection  decision 
(FAR,  15.101).  Obviously,  an  acquisition  that  involves  the  use  of  a  modular  open 
systems  approach  in  the  development  of  the  system  would  involve  a  less  definitive 
requirement,  require  more  development  work,  have  greater  performance  risk,  and 
involve  more  technical  or  past  performance  considerations  playing  a  dominant  role 
in  the  source-selection  decision.  Thus,  the  use  of  a  best  value  evaluation  approach 
is  desired  for  these  types  of  acquisitions  (Meyers  &  Oberndorf,  2001 ). 

When  using  the  best-value  trade-off  process,  it  is  important  for  all  evaluation 
factors  and  significant  sub-factors  that  will  affect  contract  award  and  their  relative 
importance  to  be  clearly  stated  in  the  solicitation;  and  the  solicitation  should  state 
whether  all  evaluation  factors  other  than  cost  or  price,  when  combined,  are 
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significantly  more  important  than,  approximately  equal  to,  or  significantly  less 
important  than  cost  or  price.  This  process  permits  trade-offs  among  cost  or  price 
and  non-cost  factors  and  allows  the  government  to  accept  other  than  the  lowest 
priced,  technically  acceptable  proposal  (FAR,  15.101-1). 

The  evaluation  factors  for  contract  award  listed  in  the  Section  M  of  the  Littoral 
Combat  Ship  (LCS)  Flight  0  Preliminary  Design  solicitation  reflects  the  government’s 
intention  to  award  based  on  best  value.  Specifically,  the  solicitation  states,  “the 
contract  will  be  awarded  to  the  responsible  Offeror(s)  whose  proposal  represents  the 
best  value  to  the  Government  after  evaluation  in  accordance  with  the  factors  and 
sub  factors  in  the  solicitation.  ‘Factors’  and  ’subfactors’  shall  include  all  of  the 
evaluation  factors  and  subfactors  that  are  described  in  this  Section  M”  (US  Navy, 
2003).  As  previously  referenced,  the  LCS  evaluation  factors  consist  of  two 
categories.  Technical  and  Price,  with  each  category  consisting  of  various  factors. 

The  Technical  category  includes  two  factors — Management  and  Technical.  The 
Technical  factor  includes  three  subfactors  as  listed  below: 

2. 1  Preliminary  Design  and  Systems  Analysis  Approach  to  Meet  LCS  PD- 
IRD  Requirements 

2.2  Systems  Engineering  Approach  to  accomplish  LCS  Preliminary  Design 
and  follow  on  design  and  construction 

2.3  System  Architecture  Development  and  Implementation  Approach 

The  subfactor  2.3  System  Architecture  Development  and  Implementation 
Approach  specifically  references  the  offeror’s  approach  for  developing  and 
implementing  a  wide  use  of  open  systems  for  mission  module  interfaces. 

The  Price  category  criteria  in  the  LCS  Section  M  of  the  solicitation  simply 
states  that  the  government  will  evaluate  each  Offeror’s  pricing  proposal  to  confirm 
that  the  Offeror’s  proposed  Firm-fixed  Price  for  the  performance  of  the  Statement  of 
Work  identified  in  the  Technical  Volume  of  the  Offeror’s  proposal  does  not  exceed 
the  maximum  possible  award  price.  The  solicitation  also  states  that  the  Contracting 
Officer  shall  consider  the  reasonableness  of  the  Offeror’s  proposed  price  by 
reviewing  the  pricing  data  submitted  by  the  Offeror  in  response  to  the  solicitation  and 
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comparing  such  pricing  data  against  the  Offeror’s  technical  proposal  (US  Navy, 
2003). 

Basis  for  Award 

Even  more  critical  in  acquisition  programs  using  a  MOSA  approach  is  the 
language  used  for  the  basis  for  award.  The  basis  for  award  describes  the 
government’s  method  for  selecting  the  contractor.  The  most  critical  part  of  the  basis 
for  award  language  is  the  weight,  or  relative  importance,  given  to  the  various 
proposal  evaluation  factors.  It  is  this  specific  language  in  which  the  buyer 
communicates  to  the  offerors  the  priority,  or  relative  importance,  of  the  evaluation 
factors.  Acquisition  of  modular  open  systems  approach-based  programs  should  be 
specific  in  communicating  the  relative  importance  of  the  evaluation  factors.  In 
addition,  and  more  importantly,  acquisition  of  modular  open  systems  approach- 
based  programs  should  place  greater  importance  on  proposal  evaluation  factors 
related  to  technical-related  factors.  In  the  case  of  the  LCS  Flight  0  Preliminary 
Design  solicitation,  the  following  is  an  extract  of  Section  M  of  the  solicitation: 

(a)  The  Government  intends  to  award  up  to  (3)  three  contracts  for  Preliminary 
Design  effort  set  forth  in  this  solicitation  to  the  Offerors  whose  proposals  are 
determined  to  offer  the  best  value  to  the  Government.  In  determining  which 
proposals  are  deemed  to  offer  the  best  value,  the  Government  will  evaluate 
the  strengths  and  weaknesses  noted  in  each  factor  identified  in  section  M.2  of 
this  solicitation,  with  due  consideration  being  given  to  the  relative  importance 
of  the  factors,  as  set  forth  below: 

(1)  The  Technical  Category  (consisting  of  Management  and  Technical 
factors)  is  significantly  more  important  than  the  Price  Category. 

(2)  Within  the  Technical  Category,  the  Management  factor  is  equal  to  the 
Technical  factor. 

(3)  Within  the  Management  factor,  subfactor  1.1  is  significantly  more 
important  than  the  remainder  of  the  Management  subfactors.  Subfactors  1 .2, 
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1 .3  and  1 .4  are  of  equal  importance  to  each  other,  and  each  is  more 
important  than  subfactor  1 .5.  Within  the  Technical  factor,  subfactor  2.1  is 
significantly  more  important  than  2.2  and  2.3,  which  are  of  equal  importance 
to  each  other.  (US  Navy,  2003) 

The  source-selection  process  is  obviously  critical  to  the  overall  acquisition 
program.  It  is  in  this  phase  where  the  offeror’s  proposal  is  evaluated  to  determine 
the  best  value  for  the  government.  It  should  be  noted  that  the  Instructions  to 
Offerors  (ITOs)  in  Section  L  and  the  evaluation  factors  and  criteria  stated  in  Section 
M  of  the  solicitation  must  be  consistent  and  interrelated.  These  are  the  areas 
carefully  scrutinized  by  offerors  in  making  their  bid/no  bid  determination,  as  well  as 
in  developing  their  proposals.  In  addition,  the  evaluation  factors  and  criteria  should 
be  tailored  to  meet  the  objectives  of  the  acquisition  strategy  (Garrett  &  Rendon, 
2005).  In  acquisition  strategies  that  are  based  on  the  use  of  a  modular  open 
systems  approach,  it  is  critical  that  Sections  L  and  M  are  carefully  crafted  and 
structured  to  communicate  and  incentivize  the  offerors  to  develop  management, 
technical,  and  cost  approaches  appropriate  for  achieving  the  open  systems  goals  of 
the  acquisition. 

Once  the  contract  is  awarded,  the  government  and  contractor  relationship 
then  shifts  to  a  performance  measurement  and  management  focus  in  which  the 
government  manages  the  contractor’s  performance  to  ensure  that  acquisition 
objectives  are  achieved.  One  way  of  ensuring  the  contractor  meets  these 
acquisition  objectives  is  through  the  use  of  appropriate  contract  types  and  contract 
incentives,  which  are  administered  during  the  contract  administration  phase  of  the 
acquisition.  This  is  discussed  in  the  next  section  of  this  report. 

Contract  Administration 

Contract  Administration  is  the  fifth  phase  of  the  contracting  process  and 
entails  managing  the  relationship  with  the  contractor  and  ensuring  that  each  party’s 
performance  meets  the  contract  requirements.  During  contract  administration,  the 
government’s  focus  is  on  managing  the  contractor’s  cost,  schedule,  and 
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performance.  Key  practice  activities  within  the  contract  administration  process 
include  using  an  integrated  team  approach  for  monitoring  the  contractor’s  cost, 
schedule,  and  performance,  and  having  an  established  process  for  administering 
incentive  and  award-fee  provisions  (Garrett  &  Rendon,  2005).  These  incentives  and 
award  fees  are  tools  used  to  motivate  and  incentivize  the  contractor  to  meet  specific 
performance  standards  of  the  contract.  These  incentive  techniques  will  be 
discussed  in  more  depth  later  in  this  section. 

Although  the  purpose  of  this  report  is  not  to  present  a  full  discussion  on  the 
various  contract  types  and  contract  incentives,  a  brief  description  of  the  major 
categories  of  contract  types  and  related  contract  incentives  will  be  presented.  The 
purpose  here  is  to  briefly  identify  which  contract  types  and  contract  incentives  have 
been  previously  used  in  acquisition  programs  pursuing  a  modular  open  systems 
approach.  References  will  be  made  to  a  recent  assessment  of  acquisition  programs 
by  the  Navy  Open  Architecture  Enterprise  Team  (OAET)  in  support  of  the  Navy 
Program  Executive  Office-Integrated  Weapon  System  (PEO-IWS)  (US  Navy,  2005, 
September  27). 

Contract  Types 

The  Federal  Acquisition  Regulation  (FAR)  identifies  two  major  contract 
categories:  cost  reimbursement  contracts  and  fixed-price  contracts  (FAR,  16). 

These  contract-type  categories  refer  to  the  method  of  compensation  due  to  the 
contractor  for  the  performance  of  the  contract. 

In  the  Fixed-price  Contract  category,  the  contractor  agrees  to  provide 
specified  supplies  or  services  in  return  for  a  specified  price,  either  a  lump  sum  or  a 
unit  price.  In  addition,  the  price  is  fixed  and  is  not  subject  to  change  regardless  of 
the  contractor’s  actual  cost  experience.  Only  if  the  contract  is  modified  is  the  price 
subject  to  change  (Garrett  &  Rendon,  2005).  There  are  various  types  of  fixed-priced 
contracts  such  as  Firm  Fixed  Price  (FFP),  Fixed  Price  with  Economic  Price 
Adjustment  (FP-EPA),  and  Fixed  Priced  Incentive  (FPI). 
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In  the  Cost  Reimbursement  contract  category,  the  contractor  agrees  to 
provide  a  best  effort  in  performing  the  requirements  of  the  contract,  which  is  typically 
broadly  defined  in  terms  of  specifications.  In  return,  the  contractor  is  reimbursed  for 
all  allowable  costs  up  to  the  amount  specified  in  the  contract.  Cost  allowability  is 
governed  by  the  FAR  (FAR,  31 ).  Various  types  of  Cost  Reimbursement  contracts 
include  Cost  Sharing  (CS),  Cost  Plus  Fixed  Fee,  (CPFF),  Cost  Plus  Incentive  Fee 
(CPIF),  and  Cost  Plus  Award  Fee  (CPAF). 

Contract  Incentives 

Contracts  may  include  incentives  to  provide  additional  motivation  to  the 
contractor  for  meeting  or  exceeding  certain  cost,  schedule,  or  performance 
objectives.  Contract  incentives  are  basically  of  two  types — objectively  based 
incentives  and  subjectively  based  incentives. 

Objectively  based  incentives  use  a  pre-determined  formula  to  determine  the 
rewards  (increase  of  profit  or  fee)  or  the  penalties  (reduction  of  profit  or  fee)  due  to 
the  contractor.  Examples  of  objectively  based  incentives  include  Fixed-priced 
Incentive  and  Cost  Plus  Incentive  contracts. 

Subjectively  based  incentives  include  Award  Fee  or  Award  Term  contracts. 
These  incentives  use  a  subjective  evaluation  to  determine  if  any  additional  fee  or 
term  (for  service  contracts)  is  due  to  the  contractor.  Based  on  a  subjective 
evaluation  of  the  contractor’s  effort  to  exceed  specific  requirements  in  terms  of  cost, 
schedule  or  performance  as  specified  in  the  Award  Fee  Plan  or  Award  Term  Plan, 
the  contractor  may  be  entitled  to  earn  additional  fee  or  term  on  the  contract. 

The  biggest  challenge  in  using  incentive  contracts  and  award  fee/term 
contracts  is  the  ability  to  structure  an  effective  incentive  tool  that  will  successfully 
motivate  the  contractor  to  perform  in  specified  areas  and  exceed  the  performance 
requirements.  It  is  particularly  important  to  structure  appropriate  incentive 
arrangements  that  will  result  in  the  contractor  applying  additional  emphasis  in  the 
areas  important  to  the  government.  In  acquisition  programs  using  a  modular  open 
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systems  approach,  the  government  will  want  to  incentivize  the  contractor  to  meet 
higher  levels  of  “openness”  in  the  design  and  development  of  the  system. 

As  previously  discussed,  the  performance  requirements  for  meeting  the 
“openness”  objectives  of  the  acquisition  are  typically  identified  and  described  in  the 
various  documents  of  the  solicitation  and  resulting  contract,  such  as  the  Statement 
of  Work  (SOW),  Statement  of  Objectives  (SOO),  Performance  Specifications  or 
Standards,  Instruction  to  Offerors  (ITOs)  and  Evaluation  Factors.  This  section  will 
discuss  the  various  contract  types  and  contract  incentives  used  for  incentivizing  the 
contractor.  This  report  will  specifically  look  at  how  some  recent  acquisition  programs 
have  attempted  to  incentivize  contractors  to  meet  higher  levels  of  “openness”  and 
how  these  contract  incentives  were  structured. 

Acquisition  programs  using  a  modular  open  systems  approach  are  challenged 
with  incentivizing  the  contractor  to  achieve  the  required  levels  of  “openness”  by 
meeting  or  exceeding  the  technical  requirements  of  the  contract,  as  well  as  cost  and 
schedule  requirements.  The  Award  Fee  type  of  incentive  has  been  traditionally  used 
for  motivating  the  contractor  to  excel  in  technical  performance.  All  of  the  programs 
referenced  in  conducting  this  research  used  the  Award  Fee  process  as  a  tool  for 
incentivizing  the  contractor  to  achieve  a  certain  level  of  openness  in  the  design  and 
development  of  the  weapon  system.  The  Littoral  Combat  Ship  (LCS)  Mission 
Package  Integration  contract  included  a  Cost  Plus  Award  Fee  (CPAF)  with 
evaluation  categories  of  Technical  Performance  (40%),  Schedule  (20%), 
Management  (20%),  and  Cost  Performance  (20%).  The  language  incentivizing 
“openness”  could  be  found  in  the  Technical  performance  category — which  focused 
on  the  effectiveness  of  the  Contractor’s  process  for  technology  insertion  for  LCS 
Mission  Packages,  to  include  identifying  technology  candidates  (US  NAVY,  2005, 
June). 


The  Multi-mission  Maritime  Aircraft  (MMA)  system  development  and 
demonstration  program  also  uses  a  Cost  Plus  Award  Fee  (CPAF)  contract  with 
approximately  30%  of  the  award  fee  pool  tied  to  technical  evaluation  criteria.  This 
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technical  criteria  includes  systems  engineering,  identified  program  risks,  Key 
Performance  Parameters  (KPPs),  and  overall  approach  to  reducing  total  ownership 
costs  (TOC)  (US  Navy,  2005,  September  29b). 

The  Common  Display  Enterprise  System  (CEDS)  Draft  RFP  also  included 
CPAF  contract  line  items  (CLINS)  as  well  as  Fixed  Price  Incentives  (FPI).  The 
CEDS  award  fee  evaluation  categories  included  Technical  Performance  (30%), 
Schedule  Performance  (25%),  Management  Performance  (20%),  and  Cost 
Performance  (25%).  The  “openness”  language  in  the  CEDS  Award  Fee  is 
referenced  in  the  Technical  Performance  and  described  in  the  CEDS  System 
Requirements  Documents  (SRD).  The  CEDS  DRFP  also  includes  FPI  line  items  for 
the  production  units  for  Year  1  (US  Navy,  2005,  August  30). 

Another  example  of  incentives  and  award  fees  supporting  an  open  systems 
approach  is  the  US  Navy’s  Mobile  User  Cbjective  System  (MUCS)  program.  The 
Navy’s  MUCS  system  is  designed  to  replace  the  Ultra  Fligh  Frequency  (UHF) 
Follow-on  satellite  system  currently  in  operation  and  to  provide  support  to  worldwide, 
multi-service,  mobile,  and  fixed-site  terminal  users.  MUCUS  will  be  a  satellite 
communication  system  that  is  expected  to  provide  low-data  rate  voice  and  data 
communications  capable  of  penetrating  most  weather,  foliage,  and  manmade 
structures.  MUCS  consists  of  a  network  of  advanced  UHF  satellites  and  multiple 
ground  segments  (GAC,  2005,  March  31).  The  MUCS  contract  contains  Cost  Plus 
Incentive  Fee  (CPIF),  Fixed-price  Incentive  (FPI),  and  Cost  Plus  Award  Fee  (CPAF) 
incentives.  This  elaborate  fee  arrangement  is  designed  to  balance,  integrate,  and 
incentivize  cost,  schedule,  and  performance  (US  Navy,  2005,  September  29a).  The 
MUCS  contract  consists  of  four  different  types  of  fees.  The  Mission  Success  Fees 
(CPAF)  constitute  one-third  of  all  fees  and  are  paid  only  after  successful  on-orbit 
delivery  of  satellites.  Milestone  Fees  (CPAF)  also  constitute  one-third  of  all  fees  and 
are  interim  payments  pending  successful  on-orbit  delivery  of  both  first  and  second 
satellites.  Target  Fees  (CPIF)  constitute  one  third  of  all  fees  and  serve  as  a  “fee 
cash  flow”  between  event-based  milestones.  An  additional  Bonus  Fee  (CPAF)  is 
available  after  completion  of  Risk  Reduction  Design  Development  (RRDD)  if  the 
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contractor  earns  100%  Mission  Success,  and  final  costs  are  less  than  target  costs. 
Also  included  in  the  MUOS  contract  is  an  FPIF/AF  for  the  remaining  satellites  of  the 
constellation  (US  Navy,  2005,  September  29a).  Figure  12  provides  additional  details 
on  the  MUOS  contract  incentive  structure. 


Figure  12.  Contracting  Approaches — Incentive  Structure 


(CPIF/AF  Portion) 


CPIF/CPAF 

Baseline:  12% 
Maximum:  18%* 


H*Only  If  undeiTun  of  5%  with  100%  ratings 
on  all  milestones  and  full  mission  success 


Incentive  Fee 
(Target:  4%.  Maximum:  7%) 


Contractor  controls  the  cost 
over  life  of  effort. 

Intentional  so  PM  cannot  rate 
(or  overlook)  cost  efficiency  via 
award  fee  process. 

PM  rates  use  of  EVMS  via 
Events-Based  Milestone  award 
fee^  I 


Milestones  Toward  Mission  Success 
(4%  Award  Fee) 

•  Contractor  controls  interim  schedule. 

•  Govt,  sets  the  event-based  milestones  (with 
a  few  dates)  and  the  fee  percentages 
(based  on  target  cost) 

•  Offerors  set  remaining  milestone  schedules 

•  Govt,  rates  each  milestone  for  tech/mamt 

performance  only. 

•  If  a  milestone  schedule  is  not  met, 
maximum  fee  payout  is  50%  of  the  allotted 
fee  pool  for  that  milestone. 
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Mission  Success 
(4%  Award  Fee) 


•  Govt,  sets  on-orbit  delivery 
dates. 

•  On-orbit  test  results  compared  to 
performance  specification. 

•  Total  System  Performance. 

•  Schedule  payout  is  function  of 
performance  payout.  Less 
capable  satellite  delivered 
early/on-tl me  increases  fee  less. 


♦  Bonus  Fee:  (b)  0-2%[« --f- 


Bonus  Fee:  (a)  1%  ■< 


As  a  bonus.  IF  the  contractor  meets  or  underruns  target  cost  AND  achieves  full  mission  success,  the  Govt,  will 
pay  contractor:  (a)  additional  1%  fee:  and  (b)  Govt.’s  underrun  savings  (up  to  2.0%  of  target  cost)  based  on 
milestone  schedules  met  and  the  performance  ratings  of  such  milestones. 


Source:  Adapted  from  SPAWAR/PEO  Space  Systems  briefing  presented  at  Naval  Enterprise  Open  Architecture  Contracts 
Symposium,  29  September  2005. 


The  MOUS  incentive  award  fee  approach  is  unique  in  that  it  maximizes  the 
benefits  and  minimizes  the  risks  of  implementing  an  open  systems  architecture. 

This  incentive/award  fee  approach  is  designed  to  empower  the  contractor  with 
responsibility  for  using  an  open  systems  approach  and  for  measuring  the  costs  and 
benefits  of  “openness”  against  the  contractor’s  bottom  line.  If  the  costs  and  benefit 
analysis  results  in  executing  an  open  systems  approach,  both  the  contractor  and 
government  save  money.  If  the  costs  and  benefits  to  executing  an  open  systems 
approach  are  not  executable,  the  contractor  and  government  avoid  schedule  delays 
and  cost  growths.  Once  again,  the  MUOS  program  is  buying  a  networked 
constellation  of  satellites  that  is  leveraging  the  open  systems  approach  in 
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development  and  maintenance,  and  not  buying  separate  satellites  that  must  meet 
individual  or  separate  open  systems  requirements.  Thus,  the  contractor  is 
responsible  for  total  system  performance  and  constellation  performance,  is  given 
control  of  over  80%  of  Mission  Success  Fee  and  profit,  and  is  responsible  for 
managing  cost  control  and  interim  schedule.  This  forces  the  contractor  to  have  a 
long-term  perspective  when  it  comes  to  using  open  systems  and  the  use  of 
Commercial  Off-the-Shelf  (COTS)  versus  developmental  systems  (US  Navy,  2005, 
September  29a). 

A  new  type  of  incentive  tool  that  is  currently  very  successful  is  the  Award 
Term  incentive.  Award  Term  is  similar  to  Award  Fee;  it  differs  only  in  that  an  Award 
Term  contract  ties  the  length  of  the  contract’s  period  of  performance  to  the 
performance  of  the  contractor.  Contractors  with  good  performance  may  have  the 
term  of  the  contract  extended,  or  contractors  with  poor  performance  may  have  the 
contract  term  reduced  (Garrett  &  Rendon,  2005).  The  Littoral  Combat  Ship  (LCS) 
Mission  Package  Integrator  contract  included  an  Award  Term  incentive  as  well  as  an 
Award  Fee  incentive,  previously  discussed.  The  Award  Term  incentive  consisted  of 
the  following  evaluation  categories:  Technical  Performance  (40%),  Schedule  (20%), 
Management  (20%),  and  Cost  Performance  (20%).  An  element  of  the  Technical 
Performance  category  included  the  effectiveness  of  the  Contractor’s  process  for 
technology  insertion  for  LCS  Mission  Packages  including  identifying  technology 
candidates  (US  Navy,  2005,  June). 

The  selection  of  contract  types  and  contract  incentives  requires  careful 
planning,  implementation,  management,  and  measurement  to  ensure  its  success  in 
incentivizing  contractors  and  improving  performance  (Garrett  &  Rendon,  2005). 
Programs  that  are  encouraging  the  use  of  a  modular  open  systems  approach  in  the 
development  of  the  system  should  incorporate  Award  Fee  and  Award  Term 
incentives.  This  is  especially  true  when  a  Statement  of  Objectives  (SOO)  is  used  to 
describe  the  government’s  required  outcomes  and  overall  objectives  and  when  the 
contractor  has  the  flexibility  to  be  innovative  in  proposing  its  management  and 
technical  approach  towards  meeting  those  outcomes  and  objectives. 
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Contract  Closeout 

The  final  phase  of  the  contracting  process  is  Contract  Closeout.  Contract 
Closeout  is  the  process  of  verifying  that  all  administrative  matters  are  concluded  on 
a  physically  complete  contract.  This  involves  accepting  final  deliveries  and  making 
final  payment  to  the  contractor,  as  well  as  completing  and  settling  the  contract  and 
resolving  any  open  items.  Key  practice  activities  within  the  contract  closeout  phase 
include  using  checklists  and  forms  for  ensuring  proper  documentation  of  closed 
contracts  and  maintaining  a  “lessons  learned  and  best  practices”  database  for  use  in 
future  contracts  and  projects  (Garrett  &  Rendon,  2005).  The  contract  closeout 
phase  is  often  forgotten  and  has  traditionally  been  considered  an  administrative 
burden  or  relegated  to  a  clerical  or  non-essential  task.  An  important  aspect  of 
completing  and  closing  out  the  contract  is  conducting  a  final  evaluation  of  the 
contractor’s  performance  on  the  contract  in  terms  of  meeting  cost,  schedule,  and 
performance  objectives.  This  final  contractor  evaluation  will  be  used  as  a  past- 
performance  evaluation  of  the  contractor  in  future  contract  competitions  and  source 
selections. 

As  previous  stated,  contractor  past  performance  is  a  critical  evaluation  factor 
for  major  source  selections  and  is  listed  as  an  evaluation  factor  under  Section  M  of 
the  solicitation.  Ensuring  the  final  contractor  performance  evaluation  is  completed 
during  the  contract  closeout  process  is  critical  in  ensuring  that  information  is 
available  for  use  in  a  future  source  selection.  In  acquisitions  using  a  modular  open 
systems  approach,  a  critical  proposal  evaluation  factor  listed  in  Section  M  of  the 
solicitation  should  be  the  contractor’s  past  performance  and  recent  experience  in 
working  in  an  open  systems  approach  environment.  Past  performance  is  a 
mandatory  proposal  evaluation  criterion  for  major  source  selections  in  accordance 
with  FAR  15.304.  The  Department  of  Defense  (DoD)  uses  the  Contractor 
Performance  Assessment  Report  (CPAR)  to  conduct  periodic  and  final  evaluation  of 
the  contractor’s  performance.  Systems  engineering  is  a  major  contractor  past- 
performance  assessment  element,  and  the  CPAR  should  be  used  to  evaluate  the 
contractor’s  adherence  to  open  systems  standards  and  MOSA  requirements  on 
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open  systems-based  acquisitions.  Using  the  CPAR  evaluation  tool,  the  government 
can  document  excellent  or  poor  contractor  performance  in  terms  of  meeting  contract 
“openness”  requirements,  and  this  documentation  can  then  be  used  in  future  source 
selections  (Office  of  the  Undersecretary  of  Defense  (AT&L),  2005). 

Summary  of  Contracting  Process 

As  can  be  seen  from  the  discussion  on  the  contracting  implications  of  using  a 
modular  open  systems  approach,  there  are  critical  areas  in  which  the  government 
must  be  specific  and  clear  in  communicating  the  “openness”  requirements  to  the 
contractor.  During  each  of  the  six  phases  of  the  contracting  process — procurement 
planning,  solicitation  planning,  solicitation,  source  selection,  contract  administration, 
and  contract  closeout,  there  are  specific  activities,  documents,  and  practices  that  the 
government  must  leverage  in  order  to  require,  mandate,  encourage,  motivate,  or 
incentivize  the  contractor  to  push  for  openness  in  the  design,  development,  and 
acquisition  of  the  procured  system.  It  should  be  noted  that  the  areas  discussed  in 
this  research  do  not  encompass  the  totality  of  the  contracting  process  or  each  of  the 
specific  phases,  only  the  most  critical  and  significant  areas  within  each  contracting 
phase  that  may  be  affected  by  using  a  modular  open  systems  approach.  Figure  13 
summarizes  the  main  areas  that  were  discussed  in  identifying  the  MOSA 
implications  on  the  procurement  process. 
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Figure  13.  MOSA  Implications  on  the  Procurement  Process 


M  M 


Source:  Adapted  from  Contract  Management:  Organizational  Assessment  Tools^  Garrett  and  Rendon,  NCMA. 
2005. 


As  can  be  seen  from  Figure  13  and  the  discussion  on  the  contracting  process 
and  the  various  activities  and  documents  used  in  the  process,  the  processes, 
activities,  and  documents  are  basically  consistent  with  many  acquisitions.  That  is, 
most  acquisition  programs  will  start  with  an  Initial  Capabilities  Documents  (ICD),  a 
system  specification,  a  requirements  document  such  as  a  SCO  or  SOW,  and  a 
solicitation  document.  Although  these  processes,  activities,  and  documents  are 
established  and  consistent,  there  are  some  options  in  how  the  government  conducts 
these  processes.  The  government’s  method  for  conducting  these  processes  has  an 
impact  on  the  level  of  flexibility  and  innovation  used  by  the  contractor  in  designing 
and  developing  its  proposed  solution.  Earlier  in  this  research,  we  discussed  the 
different  strategies  for  determining  the  roles  and  responsibilities  of  the  government 
and  the  contractor  in  conducting  an  acquisition  based  on  using  open  systems.  We 
referred  to  Meyers  and  Oberndorf’s  work  (2001)  on  the  various  approaches  to 
determining  the  roles  and  responsibilities  of  the  government  and  contractor  and  their 
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effect  on  the  degree  of  control  of  the  interface  standards  and  the  source  of  that 
control  (See  Figure  5).  This  discussion  is  now  extended  as  we  relate  the  degree  and 
source  of  control  of  the  interfaces  and  standards  to  the  contractual  documents  that 
determine  and  develop  those  interfaces.  The  degree  and  source  of  control  of  the 
interfaces  and  standards  is  based  on  the  degree  and  source  of  control  required  by 
the  contractual  documents  that  determine  and  develop  those  interfaces.  The  degree 
and  source  of  control  shared  between  the  government  and  contractor  has  an  impact 
on  the  level  of  flexibility  and  innovation  used  by  the  contractor  in  designing  and 
developing  its  proposed  solution.  The  more  control  given  to  the  contractor  in 
determining  the  type  of  interfaces  and  standards  in  designing  and  developing  its 
solution  will  be  a  critical  factor  in  achieving  the  objectives  of  a  MOSA-based 
acquisition.  Figure  14  is  adapted  from  the  Defense  Acquisition  University  (DAU) 
Systems  Engineering  Fundamentals  guide  and  describes  four  options  available  to 
the  government  for  managing  the  contracting  process  in  support  of  an  acquisition 
program  using  a  modular  open  systems  approach  {Systems  engineering 
fundamentals,  2001 ).  Each  option  provides  a  different  level  of  opportunity  for  the 
contractor  to  have  flexibility  and  use  innovation  in  developing  its  proposed  solution. 


Figure  14.  Options  for  Determining  Roles  and  Responsibilities 
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Source:  Adapted  from  Systems  Engineering  Fundamentals.  DAU.  2001. 
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For  example,  in  Option  1,  the  government  develops  the  Initial  Capabilities 
Documents  (ICD)  (which  kicks  off  the  acquisition),  the  systems  specification  (which 
is  based  on  the  ICD),  and  the  Statement  of  Work  (SOW)  (which  reflects  the  system 
specification).  The  specification  and  SOW  are  released  to  the  offerors,  along  with 
the  Instructions  to  Offerors  (ITOs)  and  Evaluation  Factors.  The  offerors  then 
respond  with  a  proposal  for  developing  a  solution  that  satisfies  the  SOW  and 
specification.  Obviously,  this  option  provides  the  offerors  very  little  flexibility  for 
developing  the  proposal  and,  thus,  limits  the  degree  of  innovation  the  offeror  can  use 
in  developing  its  solution.  This  limited  flexibility  and  innovation  is  definitely  an 
obstacle  to  meeting  the  objectives  of  an  open  systems  approach.  Without  flexibility 
and  allowance  for  innovation  in  developing  proposals,  the  offerors  would  be 
significantly  challenged  to  leverage  commercial  investment,  reduce  development 
cycle-time  and  total  ownership  costs,  ensure  system  interoperability,  enhance 
commonality  and  reuse  of  components,  enhance  access  to  cutting-edge 
technologies  and  products  from  multiple  suppliers,  enhance  lifecycle  supportability, 
and  increase  competition  {OSJTF  guide,  2004). 

In  Option  2,  the  government  uses  a  Statement  of  Objectives  (SOO)  to 
communicate  the  end-results  and  overall  objectives  of  the  acquisition  to  the  offerors 
and  allows  the  contractor  flexibility  in  developing  the  Statement  of  Work  to  fulfill  the 
objectives  and  end-results  of  the  Statement  of  Objectives  (SOO).  This  approach 
provides  a  little  more  leverage  in  achieving  the  objectives  of  using  a  MOSA 
approach  by  allowing  the  contractor  more  input  in  determining  the  details  of 
designing  and  developing  the  system  being  acquired. 

Option  3  provides  the  approach  with  the  greatest  degree  of  flexibility  and 
innovation  on  the  part  of  the  offeror.  In  this  approach,  the  government  provides  the 
ICD  to  the  offerors,  and  allows  the  offerors  to  propose  the  system  specification. 

Work  Breakdown  Structure,  and  Statement  of  Work.  Thus  in  this  approach,  the 
offerors  are  involved  up  front  and  early  in  the  acquisition  process  to  allow  them  the 
flexibility  to  be  innovative  in  proposing  design  solutions  in  response  to  the 
government’s  needed  capability.  It  should  be  noted  that  the  government  always 
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maintains  control  of  the  ICD  capability  requirement,  and  in  each  option,  the 
government  communicates  to  the  offerors  proposal  instructions  (Section  L),  and  the 
government  identifies  its  areas  of  concern  through  the  use  of  evaluation  factors 
(Section  M). 

Acquisition  programs  using  a  modular  open  systems  approach  should  select 
an  approach  that  will  allow  the  offerors  the  maximum  flexibility  in  using  innovative 
and  leading  edge  technologies  in  proposing  the  development  and  design  of  their 
solution.  This  will  then  enable  the  government  to  achieve  the  objectives  of  using  a 
MOSA  approach  in  the  management  of  the  acquisition  program. 
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Intellectual  Property  Issues 


Although  this  research  was  specifically  focused  on  the  implications  on  the 
contracting  process  from  using  a  modular  open  systems  approach,  and  not 
necessarily  on  any  specific  contract  legal  provision,  mention  should  be  made  about 
one  of  the  most  discussed  legal  issues  related  to  using  an  open  systems 
approach — the  implications  on  intellectual  property  rights.  This  issue  concerns  the 
rights  that  contracting  parties  have  to  intellectual  property  developed  under  a 
government  contract.  In  this  discussion,  “Intellectual  Property”  means  patents, 
copyrights,  trademarks,  and  trade  secrets  (Under  Secretary  of  Defense  (AT&L), 
2001,  October  15).  Furthermore,  the  DoD  categorizes  IP  into  two  main  categories — 
patent  rights  and  technical  data  and  computer  software  rights  (2001,  October  15). 

As  the  defense  acquisition  process  continues  to  give  preference  for  commercial  off- 
the-shelf  (COTS)  items  and  the  use  of  open  systems  in  the  development  of  its 
weapon  systems,  there  will  continue  to  be  much  discussion  on  the  rights  of 
intellectual  property  and  the  extent  of  those  rights  in  government  acquisitions.  This 
section  of  this  report  is  not  intended  to  resolve  the  legal  question  of  intellectual 
property  rights  (that  would  be  best  left  to  specialized  attorneys),  but  will  provide  an 
overview  of  the  DoD  policy,  core  principles  pertaining  to  Intellectual  Property,  and 
some  key  Intellectual  Property  implications  during  the  contracting  process. 

Government  Policy 

FAR  Part  27  specifies  the  policies  and  contract  clauses  concerning  copyrights 
and  rights  in  data.  Specifically,  FAR  27  provides  the  following  general  guidance: 

(a)  The  Government  encourages  the  maximum  practical  commercial  use  of 
inventions  made  while  performing  Government  contracts. 

(b)  Generally,  the  Government  will  not  refuse  to  award  a  contract  on  the 
grounds  that  the  prospective  contractor  may  infringe  a  patent. 
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(c)  Generally,  the  Government  encourages  the  use  of  inventions  in 
performing  contracts  and,  by  appropriate  contract  clauses,  authorizes  and 
consents  to  such  use,  even  though  the  inventions  may  be  covered  by  US 
patents  and  indemnification  against  infringement  may  be  appropriate. 

(d)  Generally,  the  Government  should  be  indemnified  against  infringement  of 
US  patents  resulting  from  performing  contracts  when  the  supplies  or  services 
acquired  under  the  contracts  normally  are  or  have  been  sold  or  offered  for 
sale  by  any  supplier  to  the  public  in  the  commercial  open  market  or  are  the 
same  as  such  supplies  or  services  with  relatively  minor  modifications. 

(e)  The  Government  acquires  supplies  or  services  on  a  competitive  basis  in 
accordance  with  Part  6,  but  it  is  important  that  the  efforts  directed  toward  full 
and  open  competition  not  improperly  demand  or  use  data  relating  to  private 
developments. 

(f)  The  Government  honors  the  rights  in  data  resulting  from  private 
developments  and  limits  its  demands  for  such  rights  to  those  essential  for 
Government  purposes. 

(g)  The  Government  honors  rights  in  patents,  data,  and  copyrights,  and 
complies  with  the  stipulations  of  law  in  using  or  acquiring  such  rights. 

(h)  Generally,  the  Government  requires  that  contractors  obtain  permission 
from  copyright  owners  before  including  privately-owned  copyrighted  works  in 
data  required  to  be  delivered  under  Government  contracts.  (FAR,  27.104) 

In  addition,  FAR  27.402  provides  the  general  policy  on  data  rights: 

(a)  It  is  necessary  for  the  departments  and  agencies,  in  order  to  carry  out 
their  missions  and  programs,  to  acquire  or  obtain  access  to  many  kinds  of 
data  produced  during  or  used  in  the  performance  of  their  contracts.  Agencies 
require  such  data  to:  obtain  competition  among  suppliers;  fulfill  certain 
responsibilities  for  disseminating  and  publishing  the  results  of  their  activities; 


68 


ensure  appropriate  utilization  of  the  results  of  research,  development,  and 
demonstration  activities  including  the  dissemination  of  technical  information  to 
foster  subsequent  technological  developments;  and  meet  other  programmatic 
and  statutory  requirements.  Further,  for  defense  purposes,  such  data  are  also 
required  by  agencies  to  meet  specialized  acquisition  needs  and  ensure 
logistics  support. 

(b)  At  the  same  time,  the  Government  recognizes  that  its  contractors  may 
have  a  legitimate  proprietary  interest  (e.g.,  a  property  right  or  other  valid 
economic  interest)  in  data  resulting  from  private  investment.  Protection  of 
such  data  from  unauthorized  use  and  disclosure  is  necessary  in  order  to 
prevent  the  compromise  of  such  property  right  or  economic  interest,  avoid 
jeopardizing  the  contractor’s  commercial  position,  and  preclude  impairment  of 
the  Government’s  ability  to  obtain  access  to  or  use  of  such  data.  The 
protection  of  such  data  by  the  Government  is  also  necessary  to  encourage 
qualified  contractors  to  participate  in  Government  programs  and  apply 
innovative  concepts  to  such  programs.  In  light  of  the  above  considerations,  in 
applying  these  policies,  agencies  shall  strike  a  balance  between  the 
Government’s  need  and  the  contractor’s  legitimate  proprietary  interest.  (FAR, 
27.402) 

The  DoD  FAR  Supplement,  at  Parts  227.71  and  227.72,  provides  the  specific 
DoD  policy  and  guidance  for  data  rights.  The  DoD  policy  specifically  states: 

(a)  DoD  shall  acquire  only  the  technical  data  customarily  provided  to  the 
public  with  a  commercial  item  or  process,  except  technical  data  that — 

(1 )  Are  form,  fit,  or  function  data; 

(2)  Are  required  for  repair  or  maintenance  of  commercial  items  or 
processes,  or  for  the  proper  installation,  operating,  or  handling  of  a 
commercial  item,  either  as  a  stand  alone  unit  or  as  a  part  of  a  military 
system,  when  such  data  are  not  customarily  provided  to  commercial 
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users  or  the  data  provided  to  commercial  users  is  not  sufficient  for 
military  purposes;  or 


(3)  Describe  the  modifications  made  at  Government  expense  to  a 
commercial  item  or  process  in  order  to  meet  the  requirements  of  a 
Government  solicitation. 

(b)  To  encourage  offerors  and  contractors  to  offer  or  use  commercial  products 
to  satisfy  military  requirements,  offerors  and  contractors  shall  not  be  required, 
except  for  the  technical  data  described  in  paragraph  (a)  of  this  subsection, 
to — 


(1)  Furnish  technical  information  related  to  commercial  items  or 
processes  that  is  not  customarily  provided  to  the  public;  or 

(2)  Relinquish  to,  or  otherwise  provide,  the  Government  rights  to  use, 
modify,  reproduce,  release,  perform,  display,  or  disclose  technical  data 
pertaining  to  commercial  items  or  processes  except  for  a  transfer  of 
rights  mutually  agreed  upon.  (Defense  FAR  Supplement,  227.71) 

In  addition,  the  DoD  has  specific  policy  and  guidance  for  the  acquisition  of 
commercial  computer  software  and  commercial  computer  software  documentation, 
which  is  found  in  DFARS  227.2,  where  the  specific  policy  states: 

(a)  Commercial  computer  software  or  commercial  computer  software 
documentation  shall  be  acquired  under  the  licenses  customarily  provided  to 
the  public  unless  such  licenses  are  inconsistent  with  Federal  procurement  law 
or  do  not  otherwise  satisfy  user  needs. 

(b)  Commercial  computer  software  and  commercial  computer  software 
documentation  shall  be  obtained  competitively,  to  the  maximum  extent 
practicable,  using  firm-fixed-price  contracts  or  firm-fixed-priced  orders  under 
available  pricing  schedules. 

(c)  Offerors  and  contractors  shall  not  be  required  to — 
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(1)  Furnish  technical  information  related  to  commercial  computer 
software  or  commercial  computer  software  documentation  that  is  not 
customarily  provided  to  the  public  except  for  information  documenting 
the  specific  modifications  made  at  Government  expense  to  such 
software  or  documentation  to  meet  the  requirements  of  a  Government 
solicitation;  or 

(2)  Relinquish  to,  or  otherwise  provide,  the  Government  rights  to  use, 
modify,  reproduce,  release,  perform,  display,  or  disclose  commercial 
computer  software  or  commercial  computer  software  documentation 
except  for  a  transfer  of  rights  mutually  agreed  upon.  (Defense  FAR 
Supplement,  227.72) 

As  can  be  seen  from  the  FAR  and  DFARS  policy,  for  work  that  is  performed 
under  a  government  contract,  the  government  acquires  (subject  to  negotiations) 
certain  IP  rights.  It  should  be  noted  that  a  distinction  should  be  made  between  IP 
deliverables  and  the  license  rights  in  those  deliverables.  The  IP  deliverables  are 
those  physical  deliverables  (containing  pre-determined  content  and  format)  which 
the  contractor  is  obligated  to  provide  to  the  government  in  accordance  with  the 
contract  requirements.  “The  government  may  own  the  delivered  physical  medium 
on  which  the  IP  resides,  but  generally  it  will  not  own  the  IP  rights”  (Under  Secretary 
of  Defense  (AT&L),  2001,  October  15).  Unless  the  government  has  negotiated 
license  rights  with  the  contractor,  it  will  not  have  the  ability  to  use,  reproduce,  modify, 
and  release  the  delivered  IP.  As  stated  before,  the  government  negotiates  and 
acquires  certain  IP  rights  for  work  that  is  performed  under  a  government  contract.  In 
general,  contractors  are  permitted  to  retain  title  of  the  IP  rights  for  technical  data  and 
computer  software  that  is  developed  or  delivered  under  a  DoD  contract.  Also,  the 
DoD  will  receive  a  nonexclusive  license  to  use  that  IP,  based  on  the  commerciality  of 
the  technology,  and  negotiations  between  the  contracting  parties  (Under  Secretary 
of  Defense  (AT&L),  2001,  October  15). 
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Core  Principles  for  Intellectual  Property  Rights 

With  the  preference  for  using  COTS  and  open  systems  in  developing 
software-intensive  weapon  systems,  there  are  certain  core  principles  of  Intellectual 
Property  that  DoD  contracting  officers  should  understand.  These  core  principles, 
identified  by  the  Under  Secretary  of  Defense,  Acquisition,  Technology,  and  Logistics 
(USD(AT&L))  are  listed  in  Figure  15  (Under  Secretary  of  Defense  (AT&L),  2001, 
October  15). 


Figure  15.  Core  IP  Principles  for  Intellectual  Property 


Core  IP  Principles  for  the  DoD  Acquisition  Community 

1 .  Integrate  IP  considerations  fully  into  acquisition  strategies  for  advanced 
technologies  in  order  to  protect  core  DoD  interests. 

2.  Respect  and  protect  privately  developed  IP  because  it  is  a  valuable 
form  of  intangible  property  that  is  critical  to  the  financial  strength  of  a 
business 

3.  Resolve  issues  prior  to  award  by  clearly  identifying  and  distinguishing 
the  IP  deliverables  from  the  license  rights  in  those  deliverables. 

4.  Negotiate  specialized  IP  provisions  whenever  the  customary 
deliverables  or  standard  license  rights  do  not  adequately  balance  the 
interests  of  the  contractor  and  the  Government. 

5.  Seek  flexible  and  creative  solutions  to  IP  issues,  focusing  on  acquiring 
only  those  deliverables  and  license  rights  necessary  to  accomplish  the 
acquisition  strategy. 


Source:  Intellectual  Property:  Navigating  Through  Commercial  Waters,  USD(AT&L),  2001. 


These  five  core  principles  are  directly  applicable  to  the  previously  discussed 
phases  of  the  contracting  process. 

During  procurement  planning,  it  is  important  to  integrate  IP  considerations 
into  all  phases  of  the  systems’  lifecycle  (concept  development,  system  development 
and  demonstration,  production  and  deployment,  and  disposal),  as  well  as  in 
interoperability  and  technology  transfer.  When  conducting  market  research,  IP 
issues  should  be  considered,  e.g.,  technology  maturity  level,  adaptability  of 
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technologies,  commercial  approaches  to  data  and  license  rights,  trade-offs  between 
buying  established  technology  from  competitive  sources  and  buying  state-of-the-art 
technologies  from  non-competitive  sources,  the  receptiveness  of  firms  to  comply 
with  standard  data  rights  and  patent  clauses,  the  current  pace  of  technology,  and  the 
government’s  relative  power  in  the  market  (Under  Secretary  of  Defense  (AT&L), 
2001,  October  15). 

Using  the  results  of  the  market  research  findings,  the  DoD  contracting  officer 
should  make  good  use  of  the  FAR  guidance  at  1 .102  (d)  that  states: 

(d)  The  role  of  each  member  of  the  Acquisition  Team  is  to  exercise  personal 
initiative  and  sound  business  judgment  in  providing  the  best  value  product  or 
service  to  meet  the  customer’s  needs.  In  exercising  initiative.  Government 
members  of  the  Acquisition  Team  may  assume  if  a  specific  strategy,  practice, 
policy  or  procedure  is  in  the  best  interests  of  the  Government  and  is  not 
addressed  in  the  FAR,  nor  prohibited  by  law  (statute  or  case  law).  Executive 
order  or  other  regulation,  that  the  strategy,  practice,  policy  or  procedure  is  a 
permissible  exercise  of  authority.  (FAR,  1.102(d)) 

The  solicitation  should  include  the  standard  FAR  and  DoD  FAR  Supplement 
clauses,  in  addition  to  any  other  specialized  IP  provisions  whenever  the  standard 
clauses  do  not  adequately  balance  the  interests  of  both  contracting  parties.  In 
addition,  source  selection  decisions  should  consider  IP  issues  and  costs  as  well  as 
their  implications  on  total  cost  of  ownership.  Finally,  during  contract  administration 
and  contract  close-out,  it  is  important  for  the  government  to  protect  privately 
developed  intellectual  property,  as  this  will  support  the  foundation  for  future  open 
systems.  Contractors  invest  significant  amounts  of  time  and  resources  in  developing 
advanced,  innovative  technologies  and  rely  on  IP  rights  as  the  primary  means  to 
recoup  these  costs  (Under  Secretary  of  Defense  (AT&L),  2001,  October  15).  If 
contractors  do  not  believe  their  investment  in  innovative  technology  will  be  rewarded 
in  DoD  acquisition,  they  will  no  longer  seek  government  contracts. 
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Characteristics  of  a  Successful  MOSA-based 
Contract 


This  research  began  with  a  discussion  of  the  open-systems  concept  and  a 
description  of  a  modular  open  systems  approach  (MOSA).  The  DoD  preference  for 
using  a  modular  open  systems  approach  was  also  referenced,  along  with  the 
premise  that  the  MOSA  approach  is  an  enabler  to  achieving  the  following  objectives 
identified  in  the  OSJTF  guide  (2004): 

•  Adapt  to  evolving  requirements  and  threats 

•  Promote  transition  from  science  and  technology  into  acquisition  and 
deployment 

•  Facilitate  systems  integration 

•  Leverage  commercial  investment 

•  Reduce  the  development  cycle-time  and  total  lifecycle  cost 

•  Ensure  that  the  system  will  be  fully  interoperable  with  all  the  systems  with 
which  it  must  interface,  without  major  modification  of  existing  components 

•  Enhance  commonality  and  reuse  of  components  among  systems 

•  Enhance  access  to  cutting  edge  technologies  and  products  from  multiple 
suppliers 

•  Mitigate  the  risks  associated  with  technology  obsolescence 

•  Mitigate  the  risk  of  a  single  source  of  supply  over  the  life  of  a  system 

•  Enhance  lifecycle  supportability 

•  Increase  competition 

In  order  for  an  acquisition  strategy  to  achieve  these  objectives,  the 
contracting  officer  must  structure  the  contracting  strategy  to  be  consistent  with  and 
support  the  acquisition  objectives.  This  research  has  identified  the  various  aspects 
of  the  contracting  strategy  that  lead  to  the  achievement  of  these  MOSA  objectives. 
Based  on  this  research,  successful  contracts  supporting  a  modular  open  systems 
approach  (MOSA)  will  have  the  following  characteristics: 
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1 .  Early  involvement  and  participation  of  industry  in  the  development  of 
requirements  and  acquisition  strategy  pertaining  to  the  contracted  effort. 
This  early  involvement  and  participation  includes  conducting  Market 
research  and  the  use  of  Request  for  Information  (RFIs),  Industry 
Conferences,  and  Draft  RFPs  for  the  purpose  of  obtaining  input  and 
recommendations  from  industry  on  the  structure  of  the  contracting 
strategy  and  the  resultant  contract. 

2.  Shared  roles  between  the  government  and  contractors  in  the  development 
of  the  System  Specification  and  Statement  of  Work  (SOW)  for  the 
contracted  effort.  This  may  include  releasing  the  Initial  Capabilities 
Document  (ICD)  to  the  offerors  and  allowing  the  offerors  the  flexibility  to 
submit  innovative  plans  for  the  development  and  design  of  the  system. 

3.  A  best-value  contract  award  strategy  in  which  an  offeror’s  proposals  are 
evaluated  based  on  technical  performance,  schedule  performance,  and 
past  performance  as  well  as  on  cost  and  management  approaches. 

Higher  weights  are  given  to  non-cost  factors  such  as  technical 
performance  and  past  performance  during  the  source  selection  so  the 
contract  may  be  awarded  to  other  than  the  lowest  priced  offeror. 

4.  A  contract  structure  that  includes  incentives  to  the  contractor  for  meeting 
higher  levels  of  “openness”  standards.  These  incentives  may  include 
Incentive  Fees  (CPIF,  FPIF),  Award  Fees  (CPAF,  FPAF),  and  Award 
Term  incentives. 

5.  Documentation  of  the  contractor’s  performance  in  meeting  “openness” 
requirements  and  using  this  documented  past-performance  evaluation  in 
future  source  selections  for  contracts  that  are  using  a  modular  open 
systems  approach.  Also  included  here  is  the  establishment  of  lessons 
learned  and  best  practices  on  open  systems  practices  and  procedures. 
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Summary  and  Conclusion 


The  purpose  of  this  research  was  to  explore  the  use  of  the  modular  open 
systems  approach  (MOSA)  as  a  method  for  implementing  an  evolutionary 
acquisition  strategy  as  well  as  the  implications  of  using  such  an  approach  on  the 
contracting  process.  A  background  on  evolutionary  acquisition  was  provided 
highlighting  the  benefit  of  rapid  development  and  production  of  weapon  systems 
incrementally,  with  each  increment  providing  an  increasing  level  of  capability.  The 
modular  open  systems  approach  (MOSA)  was  identified  as  an  enabler  for  the 
evolutionary  acquisition  strategy,  and  a  brief  discussion  on  open  systems  was 
provided.  The  contractual  implications  of  using  a  modular  open  systems  approach 
were  then  discussed,  focusing  on  each  of  the  six  phases  of  the  procurement 
process.  Examples  of  MOSA-specific  contracting  activities  and  documents  were 
taken  from  some  recent  weapons  systems  acquisition  programs  such  as  the  Navy’s 
Common  Enterprise  Display  System  (CEDS)  program.  Anti-submarine  Warfare 
(ASW)/Undersea  Warfare  (USW)  Test  Information  Management  System  program. 
Multi-mission  Maritime  Aircraft  (MMA)  program.  Littoral  Combat  Ship  (LCS)  Mission 
Package  Integrator  program.  Littoral  Combat  ship  (LCS)  Flight  0  Preliminary  Design 
program,  and  the  Navy’s  Mobile  User  Objective  System  (MUOS)  program. 

Finally,  a  brief  highlight  of  intellectual  property  issues  was  provided  along  with 
a  review  of  the  applicable  major  regulatory  provisions. 

As  previously  stated,  the  MOSA  is  as  much  about  business  strategy  as  it  is 
about  technical  approach.  The  modular  open  systems  technical  approach  involves 
elements  such  as  requirements,  reference  models,  components,  interfaces, 
standards,  integration  and  testing,  and  deployment  and  support,  as  described  by 
Meyers  and  Oberndorf  (2001)  and  is  further  defined  and  expanded  on  by  the  various 
systems  engineering  guides  and  open  systems  handbooks.  These  technical 
approaches  continue  to  be  defined  and  refined  and  successfully  implemented  by 
various  defense  organizations. 
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The  business  strategy  aspect  of  using  a  modular  open  systems  approach  is 
considered  to  be  in  a  developmental  phase  of  understanding,  development,  and 
refinement  within  the  DoD  acquisition  community.  Although  the  phases  of  the 
contracting  process  are  the  same  for  MOSA-based  programs  as  they  are  for  non- 
MOSA-based  programs,  this  research  found  that  the  specific  activities  conducted 
and  documents  developed  during  the  execution  of  these  contracting  phases  have  a 
direct  influence  on  the  success  of  a  MOSA-based  program.  For  example,  the 
various  options  for  allocating  roles  and  responsibilities  between  the  government  and 
the  contractor  for  the  various  steps  in  the  acquisition  process  (such  as  the 
development  of  the  initial  capabilities  documents,  system  specification,  and  SOW) 
will  influence  the  amount  of  “openness”  in  the  program  and  the  contractor’s 
motivation  for  meeting  the  desired  level  of  openness.  This  study  indicates  that  the 
greater  degree  of  jointness  in  acquisition  roles  and  responsibilities,  as  well  as  the 
greater  degree  of  contractor-developed  acquisition  documents,  will  lead  to  a  higher 
level  of  openness. 

This  study  also  identified  early  involvement  and  participation  by  industry  in 
developing  requirements  and  acquisition  strategy  as  a  key  factor  in  successful 
MOSA-based  programs.  Program  offices  managing  a  MOSA-based  program  should 
conduct  extensive  market  research  and  industry  conferences  to  achieve  this 
contractor  involvement.  A  best-value  contract  strategy  that  is  tailored  to  emphasize 
technical  performance  in  open-based  systems  and  COTS  systems  is  also  a  critical 
factor  in  meeting  higher  levels  of  openness  in  MOSA-based  programs.  A  contract 
strategy  which  involves  developing  source  selection  evaluation  factors  specifically 
weighted  to  emphasize  an  open  systems  approach  will  be  critical  for  MOSA-based 
programs. 

As  important  as  the  acquisition  strategy  is  the  structure  of  the  contract  of  a 
MOSA-based  program.  This  study  identified  the  use  of  incentive  fees,  award  fees, 
and  award  term  contract  incentives  as  integral  to  the  success  of  MOSA-based 
programs.  These  incentives,  if  structured  appropriately,  are  effective  tools  for 


78 


motivating  and  incentivizing  contractors  to  achieve  higher  levels  of  openness  in  the 
design  and  development  of  systems. 

Finally,  the  consistent  and  aggressive  use  of  the  contractor  past-performance 
information  system,  as  well  as  the  development  and  establishment  of  lessons- 
learned  programs  and  best  practices  will  be  essential  as  more  and  more  MOSA- 
based  programs  are  initiated.  As  contractors  performing  work  on  MOSA-based 
programs  begin  to  realize  that  the  DoD  is  insistent  on  using  open  systems  in 
developing  its  major  weapon  systems,  they  should  begin  to  dedicate  the  required 
resources  to  this  method  of  developing  weapon  systems. 

A  short  note  should  be  added  about  the  effectiveness  of  the  current 
contracting  regulations  supporting  the  open  systems  approach.  As  stated  earlier  in 
this  report,  FAR  Part  39  is  specifically  focused  on  modular  contracting — but  only  as  it 
relates  to  the  acquisition  of  commercial  information  technology  systems  and  not  to 
weapon  systems  acquisition.  The  specific  contracting  activities  conducted  and 
procurement  documents  developed  that  support  a  successful  MOSA-based  program 
are  addressed  in  other  parts  of  the  FAR  and  should  be  used  as  often,  if  not  more  so, 
than  FAR  Part  39.  There  is  no  need  to  add  additional  guidance  to  FAR  Part  39,  as 
contracting  officers  and  acquisition  managers  are  trained  to  use  their  business 
judgment  and  apply  the  various  tools  from  this  contracting  tool  box,  such  as 
acquisition  strategies,  contract  types,  incentive  types,  evaluation  strategies,  and  so 
forth.  What  is  needed  is  more  training  and  education  in  the  development  and 
structuring  of  acquisition  strategies  as  well  as  contracts  that  are  conducive  to 
MOSA-based  programs — not  additional  regulatory  requirements  supporting  open- 
systems  approaches.  The  various  guides  (such  as  the  OSJTF  Guide  and  the  OUSD 
(AT&L)’s  Draft  Guide  for  Contracting  for  Systems  Engineering)  will  prove  to  be  more 
valuable  and  beneficial  than  additional  regulatory  requirements. 
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Recommendations  for  Further  Research 


This  research  explored  the  implications  of  using  a  MOSA-based  approach  on 
the  contracting  process,  focusing  on  each  of  the  six  phases  of  the  contracting 
process.  The  research  identified  the  best  practices  and  characteristics  of  successful 
MOSA-based  contracts  by  analyzing  various  contracts  such  as  the  Navy  Common 
Enterprise  Display  System  (CEDS)  program,  Littoral  Combat  Ship  (LCS)  Mission 
Package  Integrator  program,  LCS  Flight  0  Preliminary  Design  program.  Multi¬ 
mission  Maritime  Aircraft  (MMA)  program,  and  the  Mobile  User  Objective  System 
(MUOS)  program.  Thus,  this  research  was  limited  to  these  current  Navy  acquisition 
programs.  Although  all  DoD  acquisition  programs  follow  the  same  FAR  and  DFARS 
regulations  (as  well  as  the  MOSA  and  systems  engineering  guides  referenced  in  this 
research),  further  research  should  be  conducted  on  other  DoD  acquisition  programs 
(Army  and  Air  Force)  to  evaluate  the  extent  to  which  the  identified  best  practices  and 
characteristics  have  been  implemented  in  those  departments. 

In  addition,  further  detailed  investigation  should  be  conducted  on  how 
effective  award  fee  and  award  term  provisions  are  in  incentivizing  contractors  to 
achieve  higher  levels  of  openness  in  designing  and  developing  weapon  systems. 
Although  the  use  of  award  fee  and  award  term  contracts  were  identified  as  a  best 
practice  in  MOSA-based  contracts  and  were  used  in  the  contracts  referenced  in  this 
research,  given  the  recent  GAO  findings  concerning  the  use  of  award  fees  in  DoD 
contracts,  this  further  investigation  would  prove  beneficial  and  timely  (GAO,  2005, 
December  19). 

A  more  extensive  research  on  the  legal  aspects  of  intellectual  property  rights 
provisions  and  their  effect  on  contractors’  willingness  to  pursue  open  systems-based 
programs  would  also  be  beneficial  to  developing  best  practices  and  success  factors 
in  this  area.  As  previously  stated  in  this  research,  the  issue  concerning  the  rights 
that  contracting  parties  have  to  intellectual  property  developed  under  a  government 
contract  is  one  of  the  most  discussed  issues  and  often  cited  obstacles  to  using  a 
MOSA-based  approach  in  DoD  acquisitions. 
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An  analysis  of  current  major  weapon  system  acquisition  programs  should  also 
be  conducted — one  specifically  related  to  the  status  of  MOSA  implementation  that  is 
a  required  milestone  review  briefing  point  to  the  program’s  Milestone  Decision 
Authority  (Under  Secretary  of  Defense  (AT&L),  2004,  April  5). 

Another  potential  research  focus  should  be  the  results  of  the  OSJTF  Program 
Assessment  Rating  Tool  (PART)  internal  MOSA  assessments.  This  research  would 
identify  current  best  practices  (what  works)  and  lessons  learned  (what  does  not 
work)  in  terms  of  implementing  MOSA  initiatives  in  weapon  systems  (Under 
Secretary  of  Defense  (AT&L),  2004,  July  7). 

Finally,  further  investigation  is  needed  on  the  type  and  extent  of  training  that 
is  currently  provided  to  contracting  officers  in  the  area  of  MOSA-based  acquisition 
strategies.  A  review  of  the  current  Defense  Acquisition  University  and  its  contracting 
curriculum  should  be  conducted  to  determine  the  extent  of  coverage  of  MOSA 
acquisition  principles  as  well  as  the  appropriate  skill  sets  being  emphasized.  This 
review  should  also  determine  if  specialized  courses,  designed  for  all  acquisition 
management  professionals  (specifically  systems  engineers  and  contracting  officers) 
should  be  developed  to  specifically  focus  on  using  a  MOSA-based  acquisition 
approach. 
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Appendix  A; 

Suggested  Topics  for  Industry  Conferences 


•  The  Government  should  continually  emphasize  the  importance  of  the  overall 
technical  approach.  The  Government  prepared  SEP  should  be  made  available  to 
industry. 

•  The  Government  and  industry  should  discuss  trades  and  analyses  that  have  been 
conducted  during  the  requirements  generation  process.  While  solution  alternatives 
are  studied  during  this  phase  of  the  program,  the  emphasis  should  remain  on  the 
resulting  performance  requirements,  not  on  the  specifics  of  the  alternatives. 
Government  trades  and  analyses  should  be  made  available  to  industry  as 
appropriate. 

•  While  it  is  necessary  to  investigate  potential  design  solutions  that  are  responsive  to 
the  requirements,  the  Government  team  should  avoid  becoming  “fixated”  with  the 
solutions.  The  user  sometimes  becomes  enamored  with  what  he  “likes,”  the 
acquisition  team  focuses  on  the  one  that  “works,”  and  industry  has  one  it  wants  to 
“sell.”  The  team  should  focus  on  establishing  the  cost-effective  performance 
requirements  that  deliver  the  necessary  operational  capability — not  picking  the 
design  solution. 

•  The  Government  should  emphasize  that  potential  offerors  must  have  technical  and 
management  processes  implemented  during  the  program.  The  Government  team 
should  have  a  clear  understanding  of  program  requirements,  encourage  the  offerors 
to  discuss  their  technical  approach  to  the  program,  and  encourage  the  potential 
offerors  to  document  their  approach  in  a  SEP. 

•  The  Government  briefings  should  address  the  program  acquisition  approach  and 
how  it  was  established.  This  is  an  excellent  opportunity  to  reinforce  the  importance 
of  the  technical  processes  for  the  program  and  for  the  Government  to  describe  its 
technical  approach  to  the  program 

•  The  Government  team  should  recognize  that  prospective  offerors  exercise  extreme 
caution  during  open  sessions  for  fear  of  compromising  a  “competitive  advantage”  or 
revealing  a  “perceived  weakness.”  During  one-on-one  sessions,  the  discussions  are 
more  open  and  free,  but  be  sure  contractor  proprietary  data  is  always  protected. 

•  The  Government  acquisition  team  should  identify  areas  of  interest  and  encourage 
prospective  offerors  to  provide  data,  insights,  and  suggestions  that  facilitate  the 
transition  into  SDD  with  sound  performance  requirements  and  a  well  structured 
technical  approach.  The  agenda  and  topics  should  not  be  solely  left  to  the  discretion 
of  the  offerors;  the  Government  should  initiate  discussions  of  topics  addressed 
above. 

Source:  Draft  Guide  for  Contracting  for  Systems  Engineering,  2005 
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Appendix  B 


Example  of  Request  for  Information  (RFI) 


Vendors  . 

Federal  Business  Opportunities 


70-Anti-Submarine  Warfare  (ASW)/Undersea  Warfare  (USW)  Test  Information 

Management  System 


Modification  01  -  Posted  on  Jan  26,  2004 


General  Information 

Document  Type: 

Sources  Sought  Notice 

Solicitation  Number: 

N0025304Q0057 

Posted  Date: 

Jan  12,  2004 

Original  Response  Date: 

Feb  02,  2004 

Current  Response  Date: 

Feb  02,  2004 

Original  Archive  Date: 

Current  Archive  Date: 

Classification  Code: 

70  -  General  purpose  information  technology 

equipment 

Contracting  Office  Address  N00253  610  Dowell  Street  Keyport,  WA 


Description 

The  Naval  Undersea  Warfare  Center  Division  Keyport  is  conducting  market  research 
to  determine  the  interest  and  capability  of  industry  for  development  and  integration 
of  an  Anti-Submarine  Warfare  (ASWyUndersea  Warfare  (USW)  Test  Information 
Management  System.  The  system  will  provide  information  management,  data 
processing,  and  instrumentation  resources.  The  ASW/USW  Test  Information 
Management  structure  shall  be  compliant  with  DOD  Directive  5015.2,  Design 
Criteria  Standard  for  Electronic  Records  Management-Software  Applications,  and 
the  relevant  Security  Classification  Guide.  This  effort  encompasses  all  classes  of 
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information  associated  with  life  cycle  ASW/USW  test  and  evaluation,  including 
prototyping,  Developmental  Test,  Operational  Test,  Proofing,  and  In-Service 
Engineering  phases.  Information  elements  are  categorized  as  either  programmatic 
information  or  test  data,  where:  (1)Test  Programmatic  Information  includes  Test 
Plans,  TestAA/ork  Requests,  and  Test  Reports;  and  the  supporting  documentation 
such  as  ADCAP  and  MK54  torpedo  and  Unmanned  Underwater  Vehicles  (UUV) 
Specification  Documentation,  Test  Parameter  Requirements  (TPR)  documents,  and 
instrumentation  configuration  load  files.  (2)Test  data  is  raw,  processed,  and 
analyzed  range  test  data  available  in  engineering  unit  format  from  a  variety  of 
instrumentation  or  analysis  sources  throughout  the  ASW/USW  test  infrastructure, 
which  includes  fixed,  portable,  and  simulation  facilities.  It  includes  digital,  analog, 
video,  and  audio  source  data  items.  Two  categories  of  users  are  anticipated  (1)High 
Demand  Users:  Four  primary  geographically  separated  locations:  NUWC  Division 
Keyport;  NUWC  Division  Keyport,  Hawaii  Detachment,  Oahu,  HI;  NUWC  Division 
Keyport,  San  Diego  Detachment;  NUWC  Division  Newport.  (2)Lower  Demand 
Users:  Government  and  contractor  sites  in  and  around  the  greater  Puget  Sound 
area;  Distributed  test  and  training  sites  throughout  the  DOD  MRTFB  infrastructure; 
Fleet  units  pier  side  or  underway.  The  ASW/USW  Test  Information  Management 
architecture  shall  satisfy  the  following  seven  objectives.  The  technical  approach  will 
integrate,  to  the  extent  feasible  and  affordable,  each  objective.  Solutions  proposed 
may  include  hardware  and  software-based  upgrades,  modification  of  procedures, 
and/or  any  combination  of  these  that  clearly  integrates  each  objective  area  into  the 
overarching  Information  Management  architecture.  Objective  1:  Information 
Exchange,  Users  will  have  the  ability  to  exchange,  transmit,  and  receive, 
programmatic  and  test  data  information  elements  necessary  for  mission  execution. 
The  capacity  and  bandwidth  of  the  Test  Information  Management  System  must 
simultaneously  support  all  end-users  using  existing  Government  internet  access. 

The  system  will  facilitate  the  test  business  process  in  a  manner  that  has  been 
approved  by  the  Government  to  meet  information  assurance,  and  security 
requirements.  Objective  2:  Information  Access  (1)  Within  the  Test  Information 
Management  System,  users  will  have  the  ability  to  access  and  retrieve 
programmatic  and  test  data  information  for  planning,  operations,  analysis,  and 
reporting  purposes.  All  information  will  be  in  digital  format  (where  practical), 
accessible  from  engineering  workstations  with  Government  Internet  access.  Search 
capability  will  employ  DTIC  keyword  standards  and  formats;  current  and  archived 
information  will  be  accessible  using  standard  Government  PC  software  products 
(i.e.;  MS  Office  Suite,  Adobe,  Matlab...etc).  Specialized  and  tailored  products  will  be 
available  from  long-term  archives  within  24-48  hours;  server  side  processing  will  be 
maximized  to  support  data  requests  within  minutes  subject  to  bandwidth  restrictions. 
Server  side  processing  must  fully  comply  with  Government  Information  Technology 
(IT)  security  and  assurance  guidelines  as  approved  by  local  implementing  agencies. 
Role-based  privileges  will  provide  the  necessary  security  and  integrity  for  the 
system.  (2)Operational  Availability  and  Reliability  must  exceed  95%;  local  and 
national  backup  protocols  must  be  in-place  to  support  downtime  periods.  (3) 
Emerging  information  management  concepts,  namely  “Data  Merging”  and  “Data 
Mining”  are  highly  desirable  attributes  if  economically  achievable  within  the  projected 
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schedule  guidelines.  Objective  3:  Data  Storage  (1)  Within  the  Test  Information 
Management  System,  both  test  programmatic  information  and  test  data  must  be 
accessible  within  stated  timelines  therefore  the  architecture  must  have  the  capability 
to  retain  information  in  both  an  “immediately  accessible”  state,  and  an  archived  state 
for  long  term  access.  (2)Based  on  end-state  data  management  policy;  the  storage 
capacity  must  be  readily  expandable  as  further  data  is  collected  and  legacy 
information  is  converted  to  digital  format.  Data  storage  devices  and  interfaces  must 
fully  comply  with  Government  Information  Technology  (IT)  security  and  assurance 
guidelines  as  approved  by  local  implementing  agencies.  (3)The  Test  Information 
Management  System  seeks  to  comply,  within  an  acceptable  schedule  and  if  proved 
economically  practical  and  feasible,  with  common  format  standards  currently  in  use 
for  ASW/USW  systems.  Objective  4:  Magnetic  and  Optical  Storage  Mediums  Within 
the  Test  Information  Management  System,  an  on-demand  capability  to  retrieve 
archived  legacy  and  near  term  test  data  from  magnetic  or  optical  media  will  be 
available  to  support  data  requests.  Support  turn-around  time  must  not  exceed  72 
hours  from  date/time  of  request.  Conversion  and  storage  of  all  media  must  fully 
comply  with  Government  Information  Technology  (IT)  security  assurance  guidelines 
as  approved  by  local  implementing  agencies.  Objective  5:  Legacy  Non-Digital  Data 
Products.  Within:  the  Test  Information  Management  System,  on-demand  conversion 
of  legacy  ASW/USW  programmatic  information  and  test  data  to  digital  format  is 
required.  That  data  must  be  accessible  as  described  in  Objectives  1-3  above. 
Keyword  search  files  will  be  created  in  MS  Word  and/or  Adobe  PDF  formats  with 
links  to  the  referenced  documents  using  DTIC  guidelines.  Conversion  and  storage 
of  all  paper  products  must  fully  comply  with  Government  Information  Technology  (IT) 
security  and  assurance  guidelines  as  approved  by  local  implementing  agencies. 
Objective  6:  Standardization  of  Data  Products.  Within  the  Test  Information 
Management  System,  standard  data  packages  will  be  defined  and  coordinated  with 
managers  and  engineers  for  completeness  and  quality.  Scripting  or  other 
automation  mechanisms  will  be  required  to  support  standard  data  package 
publication  and  distribution.  Objective  7:  Instrumentation  and  Data  Processing 
Support.  The  Test  Information  Management  System  will  require  integration  of  many 
diverse  tools,  some  in  use,  some  being  developed,  including  but  not  limited  to;  (a) 
Mathworks  MatLab  with  Government  sponsored  toolkits  (e.g.  Data  Insight)  (b)  Real 
time  sensor  acquisition  systems  and  associated  display  applications  (c) 
Test/Exercise  resource  management,  planning,  and  scheduling  tools  (d)  Standard 
office  and  publishing  tools  (Excel,  Word,  Project,  Adobe  PDF,  etc.)  (e)Document 
management  tools  (f)  Acoustic  and  video  image  processing  tools  (g)Data 
Probe/Probe  and  its  derivatives  (Charon  Probe)  (h)lnteroperability  gateways  to 
accommodate  disparate  distributed  environments.  Schedule  Objectives  are:  (1)  FY 
2005.  Requirements  Definition  with  parallel  Proof-of-Concept  Studies;  Acquisition, 
Integration,  and  Deployment  of  Tools  and  Resources.  (2)  FY  2006.  Integration  into 
the  ASW/USW  Business  Process.  Provide  a  schedule  and/or  comments  regarding 
the  schedule  objectives.  All  packages  submitted  in  response  to  the  Request  for 
Information  (RFI)  should  include  the  following  information:  Name  and  address  of 
company,  business  size,  company  point  of  contact,  telephone  number,  fax  number, 
e-mail  address,  statement  of  capability,  and  estimated  cost.  The  capability  package 
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must  be  clear,  and  concise.  Capabilities  packages  must  be  received  no  later  than 
3:00  P.M.  PST,  2  February  2004.  THIS  IS  A  REQUEST  FOR  INFORMATION 
ONLY.  The  Government  does  not  intend  to  award  a  contract  or  any  other  type  of 
agreement  on  the  basis  of  this  synopsis  or  to  otherwise  pay  for  the  information 
solicited  under  this  synopsis.  This  is  NOT  a  request  for  a  proposal  or  an  invitation 
for  bid,  merely  a  request  for  information  only.  The  Government  is  interested  in 
obtaining  information  from  industry  to  identify  existing  commercial  off  the  shelf  test 
information  management  system,  or  ongoing  or  planned  development  efforts  for  test 
data  modernization  studies.  The  information  provided  through  the  responses  will  be 
used  to  aid  in  requirements  definition  for  future  acquisitions.  If  a  solicitation  is 
released,  it  will  be  synopsized  on  the  Navy  Electronic  Commerce  Online  (NECO) 
web  link  www.neco.navy.mil  and  on  the  Keyport  Acquisition  homepage  at 
http://kpt-eco.kpt.nuwc.navv.mil 

Point  of  Contact 

Melanie  A.  Powers,  Ph:  (360)  315-3384,  Fax:  (360)  396-7036,  Naval  Undersea 
Warfare  Center  Division  Keyport,  Attn:  Supply  Department,  Code  182,  Building  944, 
610  Dowell  Street,  Keyport,  WA  98345-7610 

Email  your  questions  to  Melanie  A.  Powers,  Contracting  Officer  at 
powersm@kpt.nuwc.navy.mil 


Register  to  Receive  Notification 


Government-wide  Numbered  Notes  You  may  return  to  Business  Opportunities 

at:  DON  NAVSEA  listed  by  [Posted  Patel 
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Appendix  C 


Extract  from  CEDS  Statement  of  Work  (SOW) 


3.1. 3.2  Compliance  To  Open  Architecture  (OA)  Requirements. 

The  Contractor  shall  maintain  a  profile  of  OA  interfaces  and  data  regarding 
OA  compliance  for  CEDS  equipment  developed  under  this  contract  using  PEO  IWS 
Open  Architecture  Computing  Environment  Design  Guidance,  VI  .0  23  August  2004, 
Open  Architecture  Computing  Environment  Technologies  and  Standards,  VI  .0  23 
August  2004  and  PEO  C4I  Rapid  Application  Integration  and  Development 
Standards,  VI. 5  (Draft)  24  Feb  02  open  architecture  guidance  documents. 

The  Contractor  shall  define,  document,  and  follow  an  open  systems  approach 
utilizing  modular  design  and  standards-based  interfaces.  The  Contractor  shall 
present  the  open  systems  plan  to  the  Government  during  all  design  reviews.  The 
following  design  approach  characteristics  shall  be  utilized: 

a.  Open  Architecture — The  Contractor  shall  ensure  that  all  requirements  are 
accounted  for  by  tracing  them  to  one  or  more  modules. 

b.  Open  Modular  Design — The  Contractor  shall  provide  the  rationale  for  the 
modularization  choices  made  to  generate  the  design.  The  Contractor’s  rationale 
shall  explicitly  address  any  tradeoffs  performed,  particularly  those  that  compromise 
the  modular  and  open  nature  of  the  system.  These  designs  shall  be  documented 
and  modeled  using  industry  standard  formats,  (e.g.,  unified  modeling  language 
(UML).),  and  using  tools  that  are  capable  of  exporting  model  information  in  a 
standard  format  (e.g.,  extensible  markup  language  (XML)  metadata  interchange 
(XMI)  format). 

c.  Interface  design  and  management — The  Contractor  shall  clearly  define  the 
component  and  system  interfaces.  The  Contractor  shall  define  and  document  all 
subsystem  and  configuration  item  (Cl)  level  interfaces  to  provide  full  functional, 
physical  and  electrical  specifications. 
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d.  Treatment  of  Proprietary  Elements — The  Contractor  shall  identify  and 
justify  the  use  of  proprietary  or  closed  interfaces,  code  modules,  hardware,  firmware, 
or  software.  It  is  the  Contractor’s  responsibility  to  protect  the  open  elements  of  the 
system  from  being  intertwined  with  the  proprietary  elements. 

e.  Open  Business  Practices — The  Contractor  shall  demonstrate  that  the 
modularity  of  the  system  design  promotes  the  identification  of  multiple  sources  of 
supply  and/or  repair,  and  supports  flexible  business  strategies  that  enhance 
subcontractor  competition.  The  Contractor  shall  identify  any  pre-existing  alternative 
for  solutions  they  have  proposed  to  custom  build.  The  Contractor  shall  identify  those 
pre-existing  items  it  intends  to  reuse.  Exceptions  to  reuse  must  be  accompanied  by 
justification,  such  as  cost,  schedule,  etc. 

f.  Peer  Review  Rights — The  Government  intends  to  procure  open 
architectures,  designs,  and  corresponding  software  components.  For  designs  or 
software  the  Government  has  Government  purpose  rights  (GPR),  the  Government 
intends  to  receive  third  party  reviews  on  an  ongoing  basis.  Proprietary  elements, 
which  the  Government  has  approved  into  open  designs  and  code,  will  not  be  subject 
to  this  review. 

g.  Technology  Refresh  Method — The  Contractor’s  architectural  approach 
shall  provide  a  viable  technology  refresh  process. 

Standards  that  are  not  specified  within  this  contract  must  be  approved  by  the 
Government  prior  to  their  use. 

3.1. 3.3  Modular  Open  Systems  Approach  (MOSA). 

The  Contractor  shall  use  a  modular  open  systems  approach  (MOSA)  to 
evaluate  the  appropriateness  of  implementing  a  modular  design  strategy  for  building 
systems  lAW  Under  Secretary  of  Defense  Memorandums:  Amplifying  DoDD  5000.1 
Guidance  Regarding  Modular  Open  Systems  Approach  (MOSA)  Implementation  and 
Instructions  for  Modular  Open  Systems  Approach  (MOSA)  Implementation.  A 
primary  consideration  in  selection  of  equipment  to  meet  the  design  functionality  shall 
be  the  impact  to  the  overall  modular  open  systems  architecture.  A  modular  open 
systems  approach  and  analysis  of  long  term  supportability,  interoperability,  and 
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growth  for  future  modifications  shall  be  major  factors  in  the  Contractor’s  final 
selection  of  equipment  and  integration  approach. 

The  architectural  approach  shall  provide  a  viable  technology  insertion 
methodology  and  refresh  strategy  that  supports  application  of  a  modular  open 
systems  approach  and  is  responsive  to  changes  driven  by  mission  requirements  and 
new  technologies. 

The  Contractor  shall  maximize  commonality  of  components  used  in  CEDS 
equipment  across  all  product  baselines.  The  Contractor  shall  develop  metrics  to 
measure  the  degree  of  success  in  achieving  commonality  goals.  The  Contractor 
shall  report  the  degree  of  commonality  success  at  program  and  design  reviews. 
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Appendix  D 


Extract  from  LCS  Mission  Package  Integrator  Statement  of 

Work  (SOW) 

3.1. 1.2 — The  Contractor  shall  propose  to  PMS  420  a  process  for  identifying 
and  selecting  new  technologies  for  inclusion  in  future  Mission  Package  spirals. 
Technology  insertion  solutions  shall  trace  directly  to  and  satisfy  a  Warfighting 
Capability  Gap,  either  to  improve  existing  functionality  (e.g.  technology  refresh)  or  to 
satisfy  a  new  requirement  as  a  result  of  the  Navy’s  continued  Capability  Gap 
Analysis.  PMS  420  desires  technology  insertion  opportunities  to  be  driven  by  “user 
pull”  not  “technology  push.”  Four  principles  which  shall  be  inherent  in  developing  this 
process  are  1)  the  practice  of  including  all  applicable  foreign  and  domestic 
governments,  industry  and  academia,  in  the  search  for  new  technology  candidates, 
and  technology  projection  2)  employment  of  Open  Systems  Architecture  (OSA) 
modularity  and  industry  standards,  3)  the  inclusion  of  a  Mission  Package  Decision 
Board  (MPDB),  under  the  leadership  of  PMS  420,  for  selecting  material  solutions  for 
inclusion  in  spirals,  and  4)  the  capture  and  inclusion  of  Fleet  input.  The  process  shall 
include  provisions  for  the  Contractor  to  prepare  Mission  Area  Gap  Analyses  at  an 
engineering  level,  leveraging  Navy’s  Centers  of  Excellence  capabilities,  and  to 
provide  recommended  solutions,  either  materiel  (new/upgraded  systems)  or  non 
materiel  (e.g.,  MP  employment  concepts).  The  Contractor  shall  document  this 
process  in  a  Spiral  Development  Plan  and  submit  to  PMS  420  for  approval. 
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Appendix  E 


Recommended  Language  for  Statements  of  Objectives  (SOO) 

If  a  SOO  is  being  used,  the  following  examples  of  objectives  may  be  used. 

The  Offeror  shall  use  modular  open  systems  approach  to: 

1.  Facilitate  development  of  a  modular  architecture  and  allow  for  affordable 
intraoperability 

2.  Ensure  that  the  system  design  is  sufficiently  flexible  and  robust  to 
accommodate  changing  technology  and  requirements 

3.  Facilitate  integration  with  other  systems  and  use  of  commercial  products 
from  multiplesources  both  in  the  initial  design  and  in  future  enhancements 

4.  Enable  technology  insertion  as  currently  available  commercial  products 
mature  and  new  commercial  products  become  available  in  the  future 

5.  Allow  for  affordable  support 

6.  Allow  continued  access  to  technologies  and  products  supported  by  many 
suppliers  (a  broad  industrial  base  which  does  not  restrict  available  sources  to  the 
detriment  of  competition) 

For  systems  that  tend  to  evolve  and  improve  with  time: 

System  design  enables  technology  insertion  as  currently  available 
commercial  products  mature  and  new  commercial  products  become  available  in  the 
future. 

Or 
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Enable  incremental  system  improvements  through  upgrades  of  individual 
hardware  or  software  modules  with  newer  modular  components  without  redesign  of 
entire  systems  or  large  portions  thereof 

If  technology  obsolescence  is  a  risk  that  must  be  managed: 

Mitigate  the  risks  associated  with  technology  obsolescence,  being  locked  into 
proprietary  technology,  and  reliance  on  a  single  source  of  supply  over  the  life  of  the 
system. 

An  overall  objective  to  take  advantage  of  the  benefits  of  MOSA: 

Build  the  system  based  on  modular  hardware  and  software  design,  choosing 
commercially  supported  specifications  and  standards  for  selected  interfaces 
(external,  internal,  functional,  and  physical)  products,  practices,  and  tools. 

Source:  {OSJTF  guide,  2004) 


100 


Appendix  F 


CONTRACT  DATA  REQUIREMENTS  LIST 


Form  Approved 
OMB  No.  0704-0188 


(1  Data  Item) 


The  public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  110  hours  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data 
sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  Information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect 
of  this  collection  of  information,  including  suggestions  for  reducing  the  burden,  to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations 
and  Reports  (0701-0188),  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no 
person  shall  be  subject  to  any  penalty  for  failing  to  comply  with  a  collection  of  information  if  it  does  not  display  a  currently  valid  OMB  control  number.  Please  DO  NOT  RETURN  your 
form  to  the  above  address.  Send  completed  form  to  the  Government  Issuing  Contracting  Officer  for  the  Contract/PR  No.  listed  in  Block  E. 


A.  CONTRACT  LINE  ITEM  NO.  B.  EXH/ATCH  NO.  C.  CATEGORY 


CLINs  0002,  0008 


1 .  DATA  ITEM  NO 

012 


4.  AUTHORITY  (Data  Acquisition  Doc.  No) 

Dl-  MISC-80711A  00JAN21 


D.  SYSTEM/ITEM  E.  CONTRACT/PR  NO. 

CEDS  N00024-PR-05-NR-46527 


2.  TITLE  OF  DATA  ITEM 

SCIENTIFIC  AND  TECHNICAL  REPORTS 


5.  CONTRACT  REFERENCE 


TDP _ TM _ OTHER  X  1 

F.  CONTRACTOR 

Selected  Prime  Contractor 


3.  SUBTITLE 

OPEN  ARCHITECTURE  (OA)  PROFILE  DOCUMENT 


6.  REQUIRING  OFFICE 


7.  DD  250  REQ 

LT 


10.  FREQUENCY 

ONE/R 


9.  DIST  STATEMENT  10.  FREQUENCY  12.  DATE  QF  1“  SUBMISSIQN 

REQUIRED  ONE/R  SEEBLK16 

8.  APR  CODE  1 1 .  AS  OF  DATE  13.  DATE  OF  SUBSEQUENT 

F  SUBMISSION 

A  N/A  SEEBLK16 


16.  REMARKS 

BLK4:  PARAGRAPH  10.2  DOES  NOT  APPLY.  CONTRACTOR  FORMAT  OF  PROFILE 
MATRIX  IS  ACCEPTABLE. 

BLK  8:  APPROVAL  OF  OPEN  SYSTEM  PROFILE  IS  REQUIRED  FOR  EACH  PART  OF 
THE  CDR.  APPROVAL  IS  REQUIRED  FQR  EACH  CEDS  CQNFIGURATIQN.  APPRQVAL 
IS  FDR  TECHNICAL  CDNTENT  AND  ACCURACY.  APPRQVAL  IS  REQUIRED  BEFDRE 
DESIGN  IS  APPRDVED.  GQVERNMENT  RESPQNSE  TIME  IS  60  DAYS.  ANY 
REJECTED  SUBMISSIQN  SHALL  BE  CQRRECTED  AND  RESUBMITTED  WITHIN  30 
DAYS  QF  THE  DATE  QF  REJECTIDN. 

BLK  9:  DISTRIBUTIDN  STATEMENT  F:  FURTHER  DISSEMINATIDN  DNLY  AS 
DIRECTED  BY  PRQGRAM  EXECUTIVE  QFFICE  FQR  INTEGRATED  WARFARE 
SYSTEMS  (PEQ  IWS6.0),  WASHINGTDN  NAVY  YARD,  DC  AS  QF  JULY  8,  2005  DR 
HIGHER  DQD  AUTHQRITY. 

BLK  12:  DUE  30  DAYS  BEFDRE  PRELIMINARY  DESIGN  REVIEW  (PDR). 

BLK  13:  THE  CQNTRACTQR’S  DA  PRDFILE  SHALL  BE  REVISED  FQR  EACH 
TECHNQLDGY  TQ  REFLECT  THE  DBSQLESCENCE/INFUSIQN  CHANGE  AS  IT 
AFFECTS  THE  EXTERNAL  QR  INTERNAL  INTERFACES  QF  THE  PRQDUCT  BASELINE. 

BLK  14:  DELIVERY  TD  BE  IN  DIGITAL  FQRMAT  TQ  THE  GQVERNMENT’S  SPECIFIED 
WEBSITE. 


PEO  IWS6.0 


14.  DISTRIBUTION 


G.  PREPARED  BY 


I.  APPROVED  BY 


101 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


102 


Appendix  G 


Extract  From  LCS  Instruction  to  Offerors  (ITOs) 

2.4  System  Architecture  Development  and  Implementation  Approach  The 

Offeror  shall  describe  its  approach  for  developing  and  implementing  a  wide 
use  of  open  systems  for  mission  module  interfaces,  C4I  systems,  FORCEnet 
and  HM&E  systems  in  accordance  with  Attachments  J-5,  and  J-10.  The 
following  will  be  considered  in  evaluating  this  subfactor: 

Technical  Architecture:  The  Offeror  shall  describe  its  technology  insertion 
methodology  and  refresh  strategy  that  supports  a  long-term  open  systems 
application  and  that  is  adaptable  to  changes  driven  by  mission  requirements  and 
new  technologies.  The  Offeror  shall  describe  how  the  modular  architecture 
integrates  with  the  ship’s  core  C4ISR  and  combat  systems. 

Navy  Open  Systems  Architecture  Conformance:  Describe  the  Offeror’s  total 
ship  computing  environment  design  approach  including  description  of 
conformance  to  Navy  Open  Architecture  standards  and  guidelines  in  Attachment 
J-10.  Describe  the  Offeror’s  approach  to  re-use  open  architecture  software 
system  component/code  within  the  LCS  design.  The  Offeror  shall  identify  how  the 
Offeror  intends  to  incorporate  OA  technical  standards  into  its  overall  design.  In 
addition,  identify  how  the  Offeror’s  proposed  design  will  address  the  elements  of 
the  functional  architecture  framework,  which  includes  IWS  Integrated  Architecture, 
OA  re-usable  applications  and  definitions  of  critical  systems  interfaces. 
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